From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 5 07:11:47 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14644 for ; Tue, 5 Nov 2002 07:11:46 -0500 (EST) Received: (qmail 26754 invoked by uid 605); 5 Nov 2002 12:14:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26747 invoked from network); 5 Nov 2002 12:14:07 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 5 Nov 2002 12:14:07 -0000 Received: from w0q7s5 (unknown [218.19.30.213]) by narn.netbsd.org (Postfix) with ESMTP id 5E8DE11122 for ; Tue, 5 Nov 2002 04:14:01 -0800 (PST) From: "guest" Subject: uncertainty principle is untenable !!! To: ietf-ssh@netbsd.org Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 2002 20:14:46 +0800 X-Priority: 3 X-Mailer: jpfree Group Mail Express V1.0 Message-Id: <20021105121401.5E8DE11122@narn.netbsd.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list please reply to hdgbyi@public.guangzhou.gd.cn or bgpgong@hotmail.com, thank you. UNCERTAINTY PRINCIPLE IS UNTENABLE By reanalysing the experiment of Heisenberg Gamma-Ray Microscope and one of ideal experiment from which uncertainty principle is derived , it is found that actually uncertainty principle can not be obtained from these two ideal experiments . And it is found that uncertainty principle is untenable. Key words : uncertainty principle; experiment of Heisenberg Gamma-Ray Microscope; ideal experiment Ideal Experiment 1 Experiment of Heisenberg Gamma-Ray Microscope A free electron sits directly beneath the center of the microscope's lens (see the picture below or AIP page: http://www.aip.org/history/heisenberg/p08b.htm). The circular lens forms a cone of angle 2A from the electron. The electron is then illuminated from the left by gamma rays--high energy light which has the shortest wavelength. These yield the highest resolution, for according to a principle of wave optics, the microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) However, in quantum mechanics, where a light wave can act like a particle, a gamma ray striking an electron gives it a kick. At the moment the light is diffracted by the electron into the microscope lens, the electron is thrust to the right. To be observed by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A. In quantum mechanics, the gamma ray carries momentum, as if it were a particle. The total momentum p is related to the wavelength by the formula p = h / L, where h is Planck's constant. (2) In the extreme case of diffraction of the gamma ray to the right edge of the lens, the total momentum in the x direction would be the sum of the electron's momentum P'x in the x direction and the gamma ray's momentum in the x direction: P'x + (h sinA) / L', where L' is the wavelength of the deflected gamma ray. In the other extreme, the observed gamma ray recoils backward, just hitting the left edge of the lens. In this case, the total momentum in the x direction is: P''x - (h sinA) / L''. The final x momentum in each case must equal the initial x momentum, since momentum is never lost (it is conserved). Therefore, the final x momenta are equal to each other: P'x + (h sinA) / L' = P''x - (h sinA) / L'' (3) If A is small, then the wavelengths are approximately the same, L' ~ L" ~ L. So we have P''x - P'x = dPx ~ 2h sinA / L (4) Since dx = L/(2 sinA), we obtain a reciprocal relationship between the minimum uncertainty in the measured position,dx, of the electron along the x axis and the uncertainty in its momentum, dPx, in the x direction: dPx ~ h / dx or dPx dx ~ h. (5) For more than minimum uncertainty, the "greater than" sign may added. Except for the factor of 4pi and an equal sign, this is Heisenberg's uncertainty relation for the simultaneous measurement of the position and momentum of an object . Reanalysis To be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A. The microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) It is the resolving limit of the microscope, and it is the uncertain quantity of the object's position. Microscope can not see the object which the size is smaller than its resolving limit dx. Therefore, to be seen by the microscope, the size of the electron must be larger than the resolving limit dx or equal to the resolving limit dx. But if the size of the electron is larger than or equal to the resolving limit dx, electron will not be in the range dx. dx can not be deemed to be the uncertain quantity of the electron's position which can be seen by microscope, dx can be deemed to be the uncertain quantity of the electron's position which can not be seen by microscope only. dx is the position's uncertain quantity of the electron which can not be seen by microscope To be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A, so we can measure the momentum of the electron. dPx is the momentum's uncertain quantity of the electron which can be seen by microscope. What relates to dx is the electron which the size is smaller than the resolving limit .The electron is in the range dx, it can not be seen by the microscope, so its position is uncertain. What relates to dPx is the electron which the size is larger than or equal to the resolving limit .The electron is not in the range dx, it can be seen by the microscope, so its position is certain. Therefore, the electron which relate to dx and dPx respectively is not the same. What we can see is the electron which the size is larger than or equal to the resolving limit dx and has certain position, dx = 0.. Quantum mechanics does not relate to the size of the object. but on the Experiment Of Heisenberg Gamma-Ray Microscope, the using of the microscope must relate to the size of the object, the size of the object which can be seen by the microscope must be larger than or equal to the resolving limit dx of the microscope, thus it does not exist alleged the uncertain quantity of the electron's position dx. To be seen by the microscope, none but the size of the electron is larger than or equal to the resolving limit dx, the gamma ray which diffracted by the electron can be scattered into any angle within the cone of angle 2A, we can measure the momentum of the electron. What we can see is the electron which has certain position, dx = 0, so that none but dx = 0£¬we can measure the momentum of the electron. In Quantum mechanics, the momentum of the electron can be measured accurately when we measure the momentum of the electron only, therefore, we can gained dPx = 0. Therefore , dPx dx =0. (6) Ideal experiment 2 Experiment of single slit diffraction Supposing a particle moves in Y direction originally and then passes a slit with width dx . So the uncertain quantity of the particle position in X direction is dx (see the picture below) , and interference occurs at the back slit . According to Wave Optics , the angle where No.1 min of interference pattern is , can be calculated by following formula : sinA=L/2dx (1) and L=h/p where h is Planck¡¯s constant. (2) So uncertainty principle can be obtained dPx dx ~ h (5) Reanalysis According to Newton first law , if the external force at the X direction does not affect particle ,the particle will keep the uniform straight line Motion State or Static State , and the motion at the Y direction unchangeable .Therefore , we can lead its position in the slit form its starting point . The particle can have the certain position in the slit, and the uncertain quantity of the position dx =0 . According to Newton first law , if the external force at the X direction does not affect particle,and the original motion at the Y direction is unchangeable , the momentum of the particle at the X direction will be Px=0 , and the uncertain quantity of the momentum will be dPx =0. Get: dPx dx =0. (6) It has not any experiment to negate NEWTON FIRST LAW, in spite of quantum mechanics or classical mechanics, NEWTON FIRST LAW can be the same with the microcosmic world. Under the above ideal experiment , it considered that slit¡¯s width is the uncertain quantity of the particle¡¯s position. But there is no reason for us to consider that the particle in the above experiment have position¡¯s uncertain quantity certainly, and no reason for us to consider that the slit¡¯s width is the uncertain quantity of the particle¡¯s position. Therefore, uncertainty principle dPx dx ~ h (5) which is derived from the above experiment is unreasonable . Concluson From the above reanalysis , it is realized that the ideal experiment demonstration for uncertainty principle is untenable . uncertainty principle is untenable. . Reference book : 1. Max Jammer. (1974) The philosophy of quantum mechanics (John wiley & sons , Inc New York ) Page 65 2. Max Jammer. (1974) The philosophy of quantum mechanics (John wiley & sons , Inc New York ) Page 67 http://www.aip.org/history/heisenberg/p08b.htm Author : Gong BingXin Address : P.O.Box A111 YongFa XiaoQu XinHua HuaDu GuangZhou 510800 P.R.China E-mail : hdgbyi@public.guangzhou.gd.cn Tel: 86---20---86856616 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 5 13:22:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03525 for ; Tue, 5 Nov 2002 13:22:43 -0500 (EST) Received: (qmail 3859 invoked by uid 605); 5 Nov 2002 18:25:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3852 invoked from network); 5 Nov 2002 18:25:06 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 5 Nov 2002 18:25:06 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17528 for ; Tue, 5 Nov 2002 10:25:06 -0800 (PST) Received: from soe-austin.central.sun.com (niaus08.Central.Sun.COM [129.153.128.126]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5IP51i018981 for ; Tue, 5 Nov 2002 11:25:06 -0700 (MST) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.1+Sun/8.12.1) with ESMTP id gA5IPkDX018758 for ; Tue, 5 Nov 2002 12:25:46 -0600 (CST) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.1+Sun/8.12.1/Submit) id gA5IPkCP018757 for ietf-ssh@netbsd.org; Tue, 5 Nov 2002 12:25:46 -0600 (CST) Date: Tue, 5 Nov 2002 12:25:46 -0600 From: Nicolas Williams To: ietf-ssh@netbsd.org Subject: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021105122546.G2432@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list GSS_Accept_sec_context() can produce tokens when its major status code is neither GSS_S_COMPLETE nor GSS_S_CONTINUE_NEEDED. RFC2743 doesn't state this anywhere but by not prohibiting this it implies the behaviour. The Kerberos GSS mechanism (RFC1964) defines error tokens; it does not state that gss_accept_sec_context() can produce these but strongly implies it. RFC1964 also does not specify numeric forms of minor codes. The MIT implementation of GSS-API and the Kerberos GSS mechanism *does* produce error tokens in some circumstances. The gsskeyex draft does not specify what to do with error tokens, though it does provide an optional SSH_MSG_KEXGSS_ERROR message for transmitting GSS error information to the client. The result of this and the fact that RFC2743 does not specify major status codes for certain conditions (leaving one to use GSS_S_FAILURE) is that there is no interoperable way of communicating to the client certain GSS-API error conditions occurring on the server side. It turns out that sending the acceptor's major and minor status codes is not an appropriate alternative to sending the actual error token to the initiator. For one, RFC1964 does not define numeric forms of its minor status codes (and MIT's implementations liberally uses codes not defined in RFC1964 and not called KG_...). Second, in some cases the major/minor codes produced by gss_accept_sec_context() may be different from those produced by gss_init_sec_context() upon receipt of an error token. GSS status codes, major and minor, are API-level concepts and should really not be used on the wire - that's what the gss error tokens are for, though, admittedly, if gss_accept_sec_context() returns an error but produces no output token, then sending the major/minor codes to the client is better than sending nothing at all. I propose that the draft be modified to say that when GSS_Accept_sec_context() returns an error but produces an output token, then the server MUST send back a SSH_MSG_KEXGSS_CONTINUE message with the error token to the client and it MUST continue to the next key exchange algorithm. Alternatively we could add a new message for the server to indicate that it had an error and in which to send the error token OR we could modify the SSH_MSG_KEXGSS_ERROR message to include an optional error token. RPCSEC_GSS (rfc2203) has a similar problem. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 06:27:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11319 for ; Thu, 7 Nov 2002 06:27:36 -0500 (EST) Received: (qmail 11589 invoked by uid 605); 7 Nov 2002 11:30:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11459 invoked from network); 7 Nov 2002 11:30:00 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Nov 2002 11:30:00 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11290; Thu, 7 Nov 2002 06:27:28 -0500 (EST) Message-Id: <200211071127.GAA11290@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-gsskeyex-05.txt Date: Thu, 07 Nov 2002 06:27:28 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol Author(s) : J. Hutzelman, J. Salowey, J. Galbraith, V. Welch Filename : draft-ietf-secsh-gsskeyex-05.txt Pages : 24 Date : 2002-11-6 The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [2] provides security services to callers in a mechanism-independent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-gsskeyex-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-05.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: <2002-11-6175254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175254.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 06:27:47 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11364 for ; Thu, 7 Nov 2002 06:27:47 -0500 (EST) Received: (qmail 11981 invoked by uid 605); 7 Nov 2002 11:30:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11859 invoked from network); 7 Nov 2002 11:30:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Nov 2002 11:30:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11309; Thu, 7 Nov 2002 06:27:33 -0500 (EST) Message-Id: <200211071127.GAA11309@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-dns-01.txt Date: Thu, 07 Nov 2002 06:27:32 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Using DNS to securely publish SSH key fingerprints Author(s) : J. Schlyter, W. Griffin Filename : draft-ietf-secsh-dns-01.txt Pages : 9 Date : 2002-11-6 This document describes a method to verify SSH host keys using DNSSEC. The document defines a new DNS resource record that contains a standard SSH key fingerprint. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dns-01.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-dns-01.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: <2002-11-6175303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dns-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dns-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175303.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 10:17:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27571 for ; Thu, 7 Nov 2002 10:17:48 -0500 (EST) Received: (qmail 425 invoked by uid 605); 7 Nov 2002 15:20:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 414 invoked from network); 7 Nov 2002 15:20:12 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 7 Nov 2002 15:20:12 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23944 for ; Thu, 7 Nov 2002 07:20:11 -0800 (PST) Received: from quirm (vpn-129-149-241-215.SFBay.Sun.COM [129.149.241.215]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7FKBLf514427 for ; Thu, 7 Nov 2002 07:20:11 -0800 (PST) Date: Thu, 7 Nov 2002 07:17:10 -0800 (PST) From: Darren J Moffat To: ietf-ssh@netbsd.org Subject: draft-ietf-secsh-dns-01.txt Fingerprint digest alg Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list 3.1.2 Fingerprint type specification The only digest algorithm listed is SHA1. I think this is inconsistant with draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as the fingerprint digest algorithm. While we are on the subject is there an update to draft-ietf-secsh-fingerprint-01.txt expected since it has now been removed from the IETF site. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 10:23:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27934 for ; Thu, 7 Nov 2002 10:23:55 -0500 (EST) Received: (qmail 3031 invoked by uid 605); 7 Nov 2002 15:26:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3024 invoked from network); 7 Nov 2002 15:26:21 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 7 Nov 2002 15:26:21 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 85ED952BD; Thu, 7 Nov 2002 16:26:19 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id BC4AD1DF6; Thu, 7 Nov 2002 16:26:17 +0100 (MET) Date: Thu, 7 Nov 2002 16:25:57 +0100 (CET) From: Jakob Schlyter To: Darren J Moffat Cc: ietf-ssh@netbsd.org Subject: Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 7 Nov 2002, Darren J Moffat wrote: > The only digest algorithm listed is SHA1. I think this is inconsistant with > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as > the fingerprint digest algorithm. yes, that is intentional - I can not see any reason for using md5. jakob -- Jakob Schlyter Network Analyst Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 10:35:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28398 for ; Thu, 7 Nov 2002 10:35:34 -0500 (EST) Received: (qmail 9861 invoked by uid 605); 7 Nov 2002 15:38:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9854 invoked from network); 7 Nov 2002 15:37:59 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 7 Nov 2002 15:37:59 -0000 Received: by mail.siliconcircus.com (Postfix, from userid 505) id 313655677; Thu, 7 Nov 2002 16:37:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 3089F3EEF; Thu, 7 Nov 2002 16:37:43 +0100 (CET) Date: Thu, 7 Nov 2002 16:37:43 +0100 (CET) From: jon@siliconcircus.com X-X-Sender: sircus@drno To: Jakob Schlyter Cc: Darren J Moffat , Subject: Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 7 Nov 2002, Jakob Schlyter wrote: > On Thu, 7 Nov 2002, Darren J Moffat wrote: > > > The only digest algorithm listed is SHA1. I think this is inconsistant with > > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as > > the fingerprint digest algorithm. > > yes, that is intentional - I can not see any reason for using md5. Wouldn't backwards compatibility be better served by requiring SHA1 and additionally recommending MD5 be provided? Better to allow users to check key fingerprints using a slightly less secure algorithm than prevent them from checking key fingerprints against servers who aren't yet up to date with the latest and greatest, no? -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 10:41:37 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28593 for ; Thu, 7 Nov 2002 10:41:37 -0500 (EST) Received: (qmail 14303 invoked by uid 605); 7 Nov 2002 15:44:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14296 invoked from network); 7 Nov 2002 15:44:00 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 7 Nov 2002 15:44:00 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id A582A52BC; Thu, 7 Nov 2002 16:43:59 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 435561DF6; Thu, 7 Nov 2002 16:43:59 +0100 (MET) Date: Thu, 7 Nov 2002 16:43:37 +0100 (CET) From: Jakob Schlyter To: jon@siliconcircus.com Cc: Darren J Moffat , Subject: Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 7 Nov 2002 jon@siliconcircus.com wrote: > Wouldn't backwards compatibility be better served by requiring SHA1 and > additionally recommending MD5 be provided? there is nothing to be backwards compatible with since sshfp isn't yet deployed. users will not verify the fingerprints distributed with sshfp themselves, their software will. why? since without dnssec validation, sshfp is practically useless and verifying the dnssec signature of the sshfp manually isn't doable. jakob -- Jakob Schlyter Network Analyst Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 15:14:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09235 for ; Thu, 7 Nov 2002 15:14:01 -0500 (EST) Received: (qmail 4291 invoked by uid 605); 7 Nov 2002 20:16:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4281 invoked from network); 7 Nov 2002 20:16:26 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Nov 2002 20:16:26 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 16:25:47 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13821 for ; Thu, 7 Nov 2002 16:25:46 -0500 (EST) Received: (qmail 10397 invoked by uid 605); 7 Nov 2002 21:28:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10390 invoked from network); 7 Nov 2002 21:28:10 -0000 Received: from mx01.nexgo.de (151.189.8.96) by mail.netbsd.org with SMTP; 7 Nov 2002 21:28:10 -0000 Received: from localhost (dsl-213-023-006-208.arcor-ip.net [213.23.6.208]) by mx01.nexgo.de (Postfix) with ESMTP id CBB9E3BEAA; Thu, 7 Nov 2002 22:28:08 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 2232134081; Thu, 7 Nov 2002 22:27:27 +0100 (CET) Date: Thu, 7 Nov 2002 22:27:26 +0100 From: Markus Friedl To: Jakob Schlyter Cc: Darren J Moffat , ietf-ssh@netbsd.org Subject: Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg Message-ID: <20021107212726.GB1472@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 07, 2002 at 04:25:57PM +0100, Jakob Schlyter wrote: > On Thu, 7 Nov 2002, Darren J Moffat wrote: > > > The only digest algorithm listed is SHA1. I think this is inconsistant with > > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as > > the fingerprint digest algorithm. > > yes, that is intentional - I can not see any reason for using md5. well we've been using md5 in openssh forever. it's because ossh only had md5 support and not sha1. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 16:26:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13845 for ; Thu, 7 Nov 2002 16:26:10 -0500 (EST) Received: (qmail 10777 invoked by uid 605); 7 Nov 2002 21:28:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10769 invoked from network); 7 Nov 2002 21:28:36 -0000 Received: from mx12.arcor-online.net (151.189.8.88) by mail.netbsd.org with SMTP; 7 Nov 2002 21:28:36 -0000 Received: from localhost (dsl-213-023-006-208.arcor-ip.net [213.23.6.208]) by mx12.arcor-online.net (Postfix) with ESMTP id 87F922DA4; Thu, 7 Nov 2002 22:28:35 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id A507634081; Thu, 7 Nov 2002 22:27:57 +0100 (CET) Date: Thu, 7 Nov 2002 22:27:57 +0100 From: Markus Friedl To: Darren J Moffat Cc: ietf-ssh@netbsd.org Subject: Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg Message-ID: <20021107212757.GC1472@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 07, 2002 at 07:17:10AM -0800, Darren J Moffat wrote: > While we are on the subject is there an update to > draft-ietf-secsh-fingerprint-01.txt expected since it has now been removed > from the IETF site. i can update the drafts, but i think it's too late for the next ietf meeting. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 16:28:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13900 for ; Thu, 7 Nov 2002 16:28:17 -0500 (EST) Received: (qmail 12239 invoked by uid 605); 7 Nov 2002 21:30:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12228 invoked from network); 7 Nov 2002 21:30:43 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 7 Nov 2002 21:30:43 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id B154A52AC; Thu, 7 Nov 2002 22:30:42 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 30E571DF6; Thu, 7 Nov 2002 22:30:41 +0100 (MET) Date: Thu, 7 Nov 2002 22:30:21 +0100 (CET) From: Jakob Schlyter To: Markus Friedl Cc: Darren J Moffat , Subject: Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg In-Reply-To: <20021107212726.GB1472@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 7 Nov 2002, Markus Friedl wrote: > On Thu, Nov 07, 2002 at 04:25:57PM +0100, Jakob Schlyter wrote: > > On Thu, 7 Nov 2002, Darren J Moffat wrote: > > > > > The only digest algorithm listed is SHA1. I think this is inconsistant with > > > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as > > > the fingerprint digest algorithm. > > > > yes, that is intentional - I can not see any reason for using md5. > > well we've been using md5 in openssh forever. it's because ossh > only had md5 support and not sha1. let me clarify this; I can not see any reason for using md5 in sshfp. I can of course change my mind if the wg strongly believes that md5 should be an option. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 17:43:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16551 for ; Thu, 7 Nov 2002 17:43:56 -0500 (EST) Received: (qmail 19253 invoked by uid 605); 7 Nov 2002 22:45:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19064 invoked from network); 7 Nov 2002 22:45:23 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 7 Nov 2002 22:45:23 -0000 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by narn.netbsd.org (Postfix) with ESMTP id BC02D1115C for ; Thu, 7 Nov 2002 14:12:48 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00837 for ; Thu, 7 Nov 2002 15:12:48 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03002 for ; Thu, 7 Nov 2002 17:12:47 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gA7MCkrL022977 for ; Thu, 7 Nov 2002 17:12:47 -0500 (EST) Message-Id: <200211072212.gA7MCkrL022977@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: send agenda items to me. Reply-To: sommerfeld@east.sun.com Date: Thu, 07 Nov 2002 17:12:46 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list We're meeting in Atlanta. Send agenda requests to me. Obvious agenda items: file transfer draft-ietf-secsh-dns-01.txt anything else? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 7 19:04:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18839 for ; Thu, 7 Nov 2002 19:04:45 -0500 (EST) Received: (qmail 26456 invoked by uid 605); 8 Nov 2002 00:07:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26449 invoked from network); 8 Nov 2002 00:07:09 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Nov 2002 00:07:09 -0000 Received: from [127.0.0.1] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1008345; Thu, 07 Nov 2002 17:07:08 -0700 Message-ID: <014501c286ba$8658a2b0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: , References: <200211072212.gA7MCkrL022977@thunk.east.sun.com> Subject: Re: send agenda items to me. Date: Thu, 7 Nov 2002 17:05:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit publickey subystem draft from VanDyke. Is the public key File format draft is ready for last call? (I think it is.) - Joseph ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Thursday, November 07, 2002 15:12 Subject: send agenda items to me. > We're meeting in Atlanta. > > Send agenda requests to me. > > Obvious agenda items: > file transfer > draft-ietf-secsh-dns-01.txt > > anything else? > > - Bill > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 10 08:39:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16249 for ; Sun, 10 Nov 2002 08:39:00 -0500 (EST) Received: (qmail 28828 invoked by uid 605); 10 Nov 2002 13:41:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28819 invoked from network); 10 Nov 2002 13:41:22 -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; 10 Nov 2002 13:41:22 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa10925; 10 Nov 2002 8:41 EST Date: Sun, 10 Nov 2002 08:41:12 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSHv2 GSS spec issue wrt gss error tokens In-Reply-To: <20021105122546.G2432@soe-austin.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 5 Nov 2002, Nicolas Williams wrote: > I propose that the draft be modified to say that when GSS_Accept_sec_context() > returns an error but produces an output token, then the server MUST send > back a SSH_MSG_KEXGSS_CONTINUE message with the error token to the > client So far, so good. I'll have to think about the semantics of that; we would want to make sure that once the server has gotten an error, the key exchange cannot succeed. and it MUST continue to the next key exchange algorithm. There is no "next key exchange algorithm". If key exchange fails, the connection is aborted. There is no second chance. > Alternatively we could add a new message for the server to indicate that > it had an error and in which to send the error token OR we could modify > the SSH_MSG_KEXGSS_ERROR message to include an optional error token. I'm not sure which of the three approaches is best. But I do agree the problem should be solved... -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 11 11:44:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24274 for ; Mon, 11 Nov 2002 11:44:21 -0500 (EST) Received: (qmail 874 invoked by uid 605); 11 Nov 2002 16:46:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 867 invoked from network); 11 Nov 2002 16:46:50 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 11 Nov 2002 16:46:50 -0000 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17396; Mon, 11 Nov 2002 09:46:49 -0700 (MST) Received: from borg.eng.sun.com (borg.Eng.Sun.COM [192.168.7.69]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABGknbB022527; Mon, 11 Nov 2002 08:46:49 -0800 (PST) Received: from borg.eng.sun.com (localhost [127.0.0.1]) by borg.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id gABGlghi029511; Mon, 11 Nov 2002 08:47:42 -0800 (PST) Received: (from nw141292@localhost) by borg.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id gABGlgAF029510; Mon, 11 Nov 2002 08:47:42 -0800 (PST) Date: Mon, 11 Nov 2002 08:47:42 -0800 From: "Nicolas Williams \[RU-CENTRAL\]" To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021111084740.A28778@borg.eng.sun.com> References: <20021105122546.G2432@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhutz@cmu.edu on Sun, Nov 10, 2002 at 08:41:12AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Nov 10, 2002 at 08:41:12AM -0500, Jeffrey Hutzelman wrote: > On Tue, 5 Nov 2002, Nicolas Williams wrote: > > > I propose that the draft be modified to say that when GSS_Accept_sec_context() > > returns an error but produces an output token, then the server MUST send > > back a SSH_MSG_KEXGSS_CONTINUE message with the error token to the > > client > > So far, so good. I'll have to think about the semantics of that; we > would want to make sure that once the server has gotten an error, the key > exchange cannot succeed. IIRC GSS-API basically guarantees that if the acceptor sends an error token to the initiator then the initiator's gss_init_sec_context() will also return an error. A misbehaved initiator may insist on sending additional tokens, but wouldn't fool the acceptor, who should proceed to terminate the key exchange immediately upon GSS_Accept_sec_context() returning an error, thus leading to failure of the connection, regardless of any further actions on the part of the client. > and it MUST continue to the next key exchange algorithm. > > There is no "next key exchange algorithm". If key exchange fails, the > connection is aborted. There is no second chance. Ah, yes, sorry. This does apply to the GSS userauth part of the draft however. > > Alternatively we could add a new message for the server to indicate that > > it had an error and in which to send the error token OR we could modify > > the SSH_MSG_KEXGSS_ERROR message to include an optional error token. > > I'm not sure which of the three approaches is best. But I do agree the > problem should be solved... Technically speaking no major/minor codes should ever be sent - the fact that a token is sent and the subsequent result codes of processing said token is all that is required for both sides to know what comes next. I.e., if GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED the acceptor doesn't have to tell the initiator, just sending the output token (and there must be one, IIRC) should suffice. If, otoh, GSS-API allows a mechanism's initiators and acceptors to get out of sync, then exchanging GSS_S_CONTINUE_NEEDED/COMPLETE/FAILURE clearly becomes necessary. But it is clear to me that this is not the case, otherwise GSS-API would explicitly require that such status codes be sent along with GSS tokens or in their stead when none are produced. But sending GSS_S_CONTINUE_NEEDED/COMPLETE/FAILURE does not hurt and I see no reason to break backwards compatibility by revising the draft in such a way as to exchange only tokens, not tokens and status codes, particularly given that at least one implementation of this draft, to my knowledge, has been widely deployed. If the existing messages are not replaced and backwards compatibility is preserved, then the minor status code field should be deprecated and the major status code field should be constrained to carry only these three status codes: GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE and GSS_S_FAILURE (for backwards compatibility, but otherwise the major status code field should be ignored by clients); and the SSH_MSG_KEXGSS_ERROR message should be deprecated. Similarly for GSS userauth. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 11 11:58:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24716 for ; Mon, 11 Nov 2002 11:58:01 -0500 (EST) Received: (qmail 7630 invoked by uid 605); 11 Nov 2002 17:00:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7623 invoked from network); 11 Nov 2002 17:00:28 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 11 Nov 2002 17:00:28 -0000 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25716; Mon, 11 Nov 2002 10:00:27 -0700 (MST) Received: from borg.eng.sun.com (borg.Eng.Sun.COM [192.168.7.69]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABH0RbB025786; Mon, 11 Nov 2002 09:00:27 -0800 (PST) Received: from borg.eng.sun.com (localhost [127.0.0.1]) by borg.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id gABH1Khi029733; Mon, 11 Nov 2002 09:01:20 -0800 (PST) Received: (from nw141292@localhost) by borg.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id gABH1KbS029732; Mon, 11 Nov 2002 09:01:20 -0800 (PST) Date: Mon, 11 Nov 2002 09:01:20 -0800 From: "Nicolas Williams \[RU-CENTRAL\]" To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021111090118.A29603@borg.eng.sun.com> References: <20021105122546.G2432@soe-austin.central.sun.com> <20021111084740.A28778@borg.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021111084740.A28778@borg.eng.sun.com>; from Nicolas.Williams@sun.com on Mon, Nov 11, 2002 at 08:47:42AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Ugh, there are no major and minor status field in any messages other the ones I think should be deprecated, so please ignore that part of the below. So, to rework this: - The SSH_MSG_KEXGSS_ERROR message should be deprecated - SSH_MSG_KEXGSS_CONTINUE should continue to be used as specified in the draft - SSH_MSG_KEXGSS_CONTINUE should also be used to send any GSS "error" tokens - SSH_MSG_KEXGSS_COMPLETE should continue to be used as specified in the draft - similarly for the SSH_MSG_USERAUTH_GSSAPI_* messages (why are they not named in a manner consistent with the SSH_MSG_KEXGSS_* messages?) These changes should preserve backwards compatibility, though it is conceivable that brittle clients speaking to servers implementing the protocol in this way may well panic or crash. Cheers, Nico On Mon, Nov 11, 2002 at 08:47:42AM -0800, Nicolas Williams [RU-CENTRAL] wrote: > If the existing messages are not replaced and backwards compatibility is > preserved, then the minor status code field should be deprecated and the > major status code field should be constrained to carry only these three > status codes: GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE and GSS_S_FAILURE > (for backwards compatibility, but otherwise the major status code field > should be ignored by clients); and the SSH_MSG_KEXGSS_ERROR message > should be deprecated. Similarly for GSS userauth. > > Cheers, > > Nico > -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 13 09:50:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03165 for ; Wed, 13 Nov 2002 09:50:48 -0500 (EST) Received: (qmail 17640 invoked by uid 605); 13 Nov 2002 14:53:18 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 13 Nov 2002 14:53:18 -0000 Message-ID: <20021113145318.17639.qmail@mail.netbsd.org> Received: (qmail 17594 invoked from network); 13 Nov 2002 14:53:17 -0000 Received: from unknown (HELO zhuhai.mbfax.com) (218.13.250.81) by mail.netbsd.org with SMTP; 13 Nov 2002 14:53:17 -0000 From: sales@mbfax.com To: ietf-ssh@netbsd.org From: eroticartwork@printbuyer.com Subject: The finest in Printed Erotic Art Reproductions Dear Sirs/Madam For the finest in Printed Erotic Art Reproductions - ..follow this link: www.printbuyer.com/eroticartwork Fine Reproductions of Original Erotic Artwork. ************************************************************************** We found your esteem company on cvs.openbsd.org's website and if you wish to be removed from our list, please return our email with Removal in the Subject: ************************************************************************** Sender: ietf-ssh-owner@netbsd.org Precedence: list From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 13 11:02:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06014 for ; Wed, 13 Nov 2002 11:02:20 -0500 (EST) Received: (qmail 1758 invoked by uid 605); 13 Nov 2002 16:04:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1751 invoked from network); 13 Nov 2002 16:04:46 -0000 Received: from unknown (HELO chinapolyglot.com) (202.106.155.97) by mail.netbsd.org with SMTP; 13 Nov 2002 16:04:46 -0000 Received: from DellXP [210.21.107.131] by chinapolyglot.com with ESMTP (SMTPD32-7.06) id A75EA97016A; Thu, 14 Nov 2002 00:01:43 +0800 Message-ID: <4116-220021131316424158@DellXP> Organization: Polyglot Ltd From: "Polyglot" To: ietf-ssh@netbsd.org Subject: Polyglot Translation Date: Thu, 14 Nov 2002 00:04:24 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=utf-7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06014 Polyglot Translation Polyglot is a professional multilingual solutions provider. Our rich experience and professional team established us as a leader in the field of multilingual solutions. Polyglot can provide fast and accurate translations of financial, legal and technical documents on over 30 languages, such as English, German, Spanish, French, Italian, Chinese, Japanese, Korean, etc. We also provide software localization, website localization, simultaneous and consecutive interpretation for international meetings. For further information, please visit our website: http://www.polyglot.com.cn Contact us at: E-mail: info+AEA-polyglot.com.cn Tel: +-86 20 8657-3608 Fax: +-86 20 8657-3965 Add: 968 Office Tower, Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: +T916y0/hf/uL0VFsU/g- +T916y0/hf/uL0VFsU/hmL04AW7Zj0E+bWRp5zYvtigCJ41GzZbloSHaEThNOGmc6Z4QwAk4wW8x2hH7PmoxTyg- +ThNOGnaElh9PDXhuestOhmIRTuxXKFkaec2L7YoAieNRs2W5aEiYhlffdoSYhlFIVzBPTTAC- +YhFO7ID9Y9BPmw-30+WRp5zYvtigB2hFHGeG4wAV/rY3d2hH/7i9FnDVKh/wx/+4vRmIZX322JU8qR0YeNZYdO9jAB- +bNVfi2WHTvZTymKAZy9lh072/wx/+4vRi+15zVMFYuz/GoLxMAFftzABiX8wAWzVMAFhDzABTi0wAWXlMAGX6XtJe0kwAg- +a2RZFv8MYhFO7I/YY9BPm49vTvZnLFcwUxYwAX9RetlnLFcwUxYwAVb9lkVPGouudoRUDFjwTyCL0VSMTqRm/08gi9EwAg- +UXNOjovmYMX/DIv3i7+V7mIRTux2hH9RV0D/Gg- http://www.polyglot.com.cn +gFR8+2W5Xw//Gg- +dTWQrg-: info+AEA-polyglot.com.cn +dTWL3Q-: (86-20) 8657 3608 +TyB3Hw-: (86-20) 8657 3965 +VzBXQP8aTi1W/V5/Xd5nOlc6je8-33+U/c- +Ti1ZLpFSXpdRmVtXaXw-968 +kK5/Fv8a-510403 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 14 16:27:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01396 for ; Thu, 14 Nov 2002 16:27:01 -0500 (EST) Received: (qmail 20554 invoked by uid 605); 14 Nov 2002 21:29:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20547 invoked from network); 14 Nov 2002 21:29:31 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 14 Nov 2002 21:29:31 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09201; Thu, 14 Nov 2002 14:29:29 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAELTS9x007439; Thu, 14 Nov 2002 16:29:28 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAELTSfR020614; Thu, 14 Nov 2002 16:29:28 -0500 (EST) Message-Id: <200211142129.gAELTSfR020614@thunk.east.sun.com> From: Bill Sommerfeld To: agenda@ietf.org cc: ietf-ssh@netbsd.org Subject: Secure Shell (SECSH) agenda for IETF 55 (Atlanta) Reply-to: sommerfeld@east.sun.com Date: Thu, 14 Nov 2002 16:29:28 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Secure Shell Working Group (secsh) TUESDAY, November 19, 2002 at 0900-1130 CHAIR: Bill Sommerfeld AGENDA: initialization vector/agenda bashing 5 minutes status of core drafts 10 minutes draft-ietf-secsh-assignednumbers draft-ietf-secsh-architecture draft-ietf-secsh-connect draft-ietf-secsh-transport draft-ietf-secsh-userauth status of other drafts 10 minutes Discussions 60 minutes GSSAPI issues (draft-ietf-secsh-gsskeyex-05.txt) Jeffrey Hutzelman File Transfer (draft-ietf-secsh-filexfer-03.txt) Secure DNS publication of key fingerprints (draft-ietf-secsh-dns-01.txt) Public Key subystem draft Joseph Galbraith (individual submission) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 11:06:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25010 for ; Mon, 18 Nov 2002 11:06:05 -0500 (EST) Received: (qmail 8228 invoked by uid 605); 18 Nov 2002 16:08:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8197 invoked from network); 18 Nov 2002 16:08:19 -0000 Received: from liandra.ietf55.ops.ietf.org (HELO liandra.pc.cs.cmu.edu) (204.42.65.139) by mail.netbsd.org with SMTP; 18 Nov 2002 16:08:19 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa09093; 18 Nov 2002 11:07 EST Date: Mon, 18 Nov 2002 11:07:34 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: "Nicolas Williams \[RU-CENTRAL\]" cc: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSHv2 GSS spec issue wrt gss error tokens In-Reply-To: <20021111090118.A29603@borg.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 11 Nov 2002, Nicolas Williams [RU-CENTRAL] wrote: > Ugh, there are no major and minor status field in any messages other the > ones I think should be deprecated, so please ignore that part of the > below. > > So, to rework this: > > - The SSH_MSG_KEXGSS_ERROR message should be deprecated No. I think you misunderstand the purpose of this message, and the reason it was added to the document. The reason for sending this message is not to signal to the client that there was an error, or to provide the client with status codes that it can use to decide how to proceed -- as you note, the status code values are implementation-dependent and not standardized. Rather, it is there to allow the server to provide status codes and/or a textual error message to the user which may be useful in determining why key exchange failed and correcting the problem. It was added specifically because we have discovered in the past that not having this information significantly impedes debugging when something breaks. If the document is unclear on this issue, we could add some clarifying text. > - SSH_MSG_KEXGSS_CONTINUE should continue to be used as specified in > the draft > > - SSH_MSG_KEXGSS_CONTINUE should also be used to send any GSS "error" > tokens > > - SSH_MSG_KEXGSS_COMPLETE should continue to be used as specified in > the draft > > - similarly for the SSH_MSG_USERAUTH_GSSAPI_* messages (why are they > not named in a manner consistent with the SSH_MSG_KEXGSS_* messages?) They are named in a manner consistant with the names used in the core SSH drafts. I believe this is appropriate and should not be changed. -- 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 Mon Nov 18 12:13:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26895 for ; Mon, 18 Nov 2002 12:13:47 -0500 (EST) Received: (qmail 18167 invoked by uid 605); 18 Nov 2002 17:16:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18160 invoked from network); 18 Nov 2002 17:16:21 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 18 Nov 2002 17:16:21 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27980; Mon, 18 Nov 2002 10:16:20 -0700 (MST) Received: from soe-austin.central.sun.com (niaus08.Central.Sun.COM [129.153.128.126]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIHGKOq008025; Mon, 18 Nov 2002 10:16:20 -0700 (MST) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAIHGDiU023743; Mon, 18 Nov 2002 11:16:13 -0600 (CST) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6/Submit) id gAIHGDfr023742; Mon, 18 Nov 2002 11:16:13 -0600 (CST) Date: Mon, 18 Nov 2002 11:16:13 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021118111613.A22254@soe-austin.central.sun.com> References: <20021111090118.A29603@borg.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhutz@cmu.edu on Mon, Nov 18, 2002 at 11:07:34AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [BTW, I will not be attending this week's IETF.] Jeff, How do you propose to fix the problem at hand, that gsskeyex does not provide a method to send GSS error tokens, and therefore has no interoperable mechanism for conveying acceptor-side errors to initiators? (forgive me, GSS-API demands that we speak of initiators and acceptors for what every other API/standard refers to as clients and servers - I'll use the terms interchangeably as SSHv2 clients will only be GSS initiators and so on). This issue does affect the user experience. Take OpenSSH w/ Simon Wilkinson's patches + krb5, for example, and slightly misconfigure Kerberos on the server side, so that it cannot accept GSS/Kerberos key exchange, then run the client (with valid Kerberos credentials available) and see what happens: the one and only message the client will have for the user is "Connection closed." (One need not even have to misconfigure Kerberos - if the server is multi-homed, with multiple canonical hostnames [one for each set of interfaces] then gsskeyex will work only when user against the interfaces whose canonical hostname matches the host's "nodename". This is because the existing open source implementations of GSS/Kerberos do not support the better GSS_C_NO_CREDENTIAL semantics in GSS_Accept_sec_context(). This scenario happens every day in at least one environment that I know of, so it is not far-fetched; having useful error messages for this and other scenarios would be great and sending the acceptor's error token is the correct way to achieve that.) At my previous job I wrote patches to implement SSH_MSG_KEXGSS_ERROR with OpenSSH and Simon's patches. This sure helped the situation, but, as you know, the minor status codes are specific to the side where they are produced, and may not be appropriate for the other side ("wrong acceptor cred" on the acceptor side may be "wrong acceptor name" on the client side; BTW, RFC1964 explicitly does not constrain implementations to the list of minor status codes listed therein, nor is MIT's implementation so constrained). Sending the GSS error token truly fixes the problem and does so in a way that is in keeping with the spirit of RFC2743 and the letter of RFC2744. The draft modifications that I propose would fix this problem in a backwards compatible way (except where clients have broken GSS-API implementations which cannot properly deal with GSS error tokens, of which I know not one). Alternatively the draft could be modified in a non-backwards compatible manner, but I believe it's too for that. More comments below. On Mon, Nov 18, 2002 at 11:07:34AM -0500, Jeffrey Hutzelman wrote: > On Mon, 11 Nov 2002, Nicolas Williams [RU-CENTRAL] wrote: > > > Ugh, there are no major and minor status field in any messages other the > > ones I think should be deprecated, so please ignore that part of the > > below. > > > > So, to rework this: > > > > - The SSH_MSG_KEXGSS_ERROR message should be deprecated > > No. I think you misunderstand the purpose of this message, and the reason > it was added to the document. The reason for sending this message is not > to signal to the client that there was an error, or to provide the client > with status codes that it can use to decide how to proceed -- as you note, > the status code values are implementation-dependent and not standardized. > Rather, it is there to allow the server to provide status codes and/or a > textual error message to the user which may be useful in determining why > key exchange failed and correcting the problem. It was added specifically > because we have discovered in the past that not having this information > significantly impedes debugging when something breaks. > > If the document is unclear on this issue, we could add some clarifying > text. I think this is somewhat disingenuous. The draft does not provide for sending of GSS error tokens, thus leaving SSH_MSG_KEXGSS_ERROR as the only, but inadequate alternative. This leads me to suspect that the draft's authors failed to understand that GSS_Accept_sec_context() can produce an output token and a final error at the same time, thus the desire for an explicit error message that conveys the major/minor status code produced by GSS_Accept_sec_context(). Had the authors understood GSS error tokens I doubt they would have bothered to define SSH_MSG_KEXGSS_ERROR. In any case, the draft says nothing about the message being for debug purposes or about minor status codes possibly being implementation specific. Having implemented SSH_MSG_KEXGSS_ERROR before (see above) I know I too missed the significance of GSS error tokens, even their existence, for some time. RFC2743 is not explicit about GSS error tokens at all, and RFC2743 being more general than RFC2744 (the C-bindings of RFC2743) one would not expect RFC2744 to be explicit about them either (but it is). Thus it would seem that it is not uncommon to find this misunderstanding of the GSS-API - and it has occurred in other protocols that ustilize the GSS-API as well. Having SSH_MSG_KEXGSS_ERROR as a debug message is fine, but it will still only help when the client and server are of similar origins (meaning that they share definitions for the minor status codes of their supported mechanisms). This limited utility makes SSH_MSG_KEXGSS_ERROR less than useful, and, given that sending GSS error tokens interoperably provides the relevant information to the client anyways I see no reason to bother with SSH_MSG_KEXGSS_ERROR and its userauth friend. That said, it is not absolutely necessary that SSH_MSG_KEXGSS_ERROR be deprecated and I am not wedded to its deprecation as a practical matter (i.e., the message is optional already), only as a matter of principle (why send the client infomartion it may not be able to decode). > > - SSH_MSG_KEXGSS_CONTINUE should continue to be used as specified in > > the draft > > > > - SSH_MSG_KEXGSS_CONTINUE should also be used to send any GSS "error" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > tokens ^^^^^^^^^^^^^ Do you object to this? This is the actual, backwards compatible draft change needed to have interoperable communications about GSS errors. This fix is interoperable because as soon as the client processes any GSS error token sent by the server the client will fail gsskey ex just as the server knows to fail it as well - SSH_MSG_KEXGSS_CONTINUE may seem inappropriate for this purpose, but only because of its name; given the need for a backwards compatible solution this additional use of SSH_MSG_KEXGSS_CONTINUE is just fine. > > - SSH_MSG_KEXGSS_COMPLETE should continue to be used as specified in > > the draft > > > > - similarly for the SSH_MSG_USERAUTH_GSSAPI_* messages (why are they > > not named in a manner consistent with the SSH_MSG_KEXGSS_* messages?) > > They are named in a manner consistant with the names used in the core SSH > drafts. I believe this is appropriate and should not be changed. How do you propose that GSS error tokens be sent back? Or do you propose that they not be sent back at all? > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 13:34:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29345 for ; Mon, 18 Nov 2002 13:34:29 -0500 (EST) Received: (qmail 23494 invoked by uid 605); 18 Nov 2002 18:37:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23473 invoked from network); 18 Nov 2002 18:37:00 -0000 Received: from liandra.ietf55.ops.ietf.org (HELO liandra.pc.cs.cmu.edu) (204.42.65.139) by mail.netbsd.org with SMTP; 18 Nov 2002 18:37:00 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa09781; 18 Nov 2002 13:36 EST Date: Mon, 18 Nov 2002 13:36:33 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSHv2 GSS spec issue wrt gss error tokens In-Reply-To: <20021118111613.A22254@soe-austin.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 18 Nov 2002, Nicolas Williams wrote: > How do you propose to fix the problem at hand, that gsskeyex does not > provide a method to send GSS error tokens, and therefore has no > interoperable mechanism for conveying acceptor-side errors to > initiators? (forgive me, GSS-API demands that we speak of initiators > and acceptors for what every other API/standard refers to as clients and > servers - I'll use the terms interchangeably as SSHv2 clients will only > be GSS initiators and so on). Sorry; I guess I was unclear. I have no problem with recommending that the SSH_MSG_KEXGSS_CONTINUE message be used to send error back error tokens, provided that the party sending the error token (which, I believe, could be the initiator or acceptor) remembers that it is in an error state and does not then allow key exchange to succeed. I only oppose dropping the SSH_MSG_KEXGSS_ERROR message, which I believe provides useful debugging information that may not be available any other way -- particularly if the mechanism in use does not generate interesting error tokens. All of the relevant messages should be optional or recommended, and we should be consistent about it. See the last paragraph of the security considerations section, in which we recommend that it be possible to configure servers _not_ to send the error message, in order to avoid giving an attacker information that may help him to break in. > I think this is somewhat disingenuous. The draft does not provide for > sending of GSS error tokens, thus leaving SSH_MSG_KEXGSS_ERROR as the > only, but inadequate alternative. This leads me to suspect that the > draft's authors failed to understand that GSS_Accept_sec_context() > can produce an output token and a final error at the same time, thus the > desire for an explicit error message that conveys the major/minor status > code produced by GSS_Accept_sec_context(). Had the authors understood > GSS error tokens I doubt they would have bothered to define > SSH_MSG_KEXGSS_ERROR. In any case, the draft says nothing about the > message being for debug purposes or about minor status codes possibly > being implementation specific. You're right; we did fail to understand that. We understand it now, and we can certainly add text to address the issue of error tokens, since it seems the right thing to do is not entirely obvious. This is not surprising, since the GSSAPI specs are notoriously difficult to fully understand. > Having SSH_MSG_KEXGSS_ERROR as a debug message is fine, but it will > still only help when the client and server are of similar origins > (meaning that they share definitions for the minor status codes of their > supported mechanisms). This limited utility makes SSH_MSG_KEXGSS_ERROR > less than useful, and, given that sending GSS error tokens interoperably > provides the relevant information to the client anyways I see no reason > to bother with SSH_MSG_KEXGSS_ERROR and its userauth friend. I disagree. The intent was never that the client would attempt to interpret the status codes, but that it would display them to the user (possibly only if an appropriate debugging option is enabled). When a user says "I tried to ssh into your machine and it didn't work", being able to get them to report the status codes can be quite useful -- especially given that users are likely to report a code accurately when they would attempt to interpret the meaning of a message. > > > - SSH_MSG_KEXGSS_CONTINUE should continue to be used as specified in > > > the draft > > > > > > - SSH_MSG_KEXGSS_CONTINUE should also be used to send any GSS "error" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > tokens > ^^^^^^^^^^^^^ > > Do you object to this? This is the actual, backwards compatible draft > change needed to have interoperable communications about GSS errors. For clarity: No, I do not object to this. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 13:42:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29570 for ; Mon, 18 Nov 2002 13:42:48 -0500 (EST) Received: (qmail 27716 invoked by uid 605); 18 Nov 2002 18:45:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27709 invoked from network); 18 Nov 2002 18:45:21 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 18 Nov 2002 18:45:21 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26896; Mon, 18 Nov 2002 11:45:21 -0700 (MST) Received: from soe-austin.central.sun.com (niaus08.Central.Sun.COM [129.153.128.126]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIIjKOq010778; Mon, 18 Nov 2002 11:45:21 -0700 (MST) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAIIjKiU028471; Mon, 18 Nov 2002 12:45:20 -0600 (CST) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6/Submit) id gAIIjK68028470; Mon, 18 Nov 2002 12:45:20 -0600 (CST) Date: Mon, 18 Nov 2002 12:45:20 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021118124520.A28364@soe-austin.central.sun.com> References: <20021111090118.A29603@borg.eng.sun.com> <20021118111613.A22254@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021118111613.A22254@soe-austin.central.sun.com>; from Nicolas.Williams@sun.com on Mon, Nov 18, 2002 at 11:16:13AM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Nov 18, 2002 at 11:16:13AM -0600, Nicolas Williams wrote: > > [...] > > (One need not even have to misconfigure Kerberos - if the server is > multi-homed, with multiple canonical hostnames [one for each set of > interfaces] then gsskeyex will work only when user against the That should read "One need not misconfigure Kerberos ..." and "... only when used against ..." > interfaces whose canonical hostname matches the host's "nodename". This > is because the existing open source implementations of GSS/Kerberos do > not support the better GSS_C_NO_CREDENTIAL semantics in > GSS_Accept_sec_context(). This scenario happens every day in at least > one environment that I know of, so it is not far-fetched; having useful > error messages for this and other scenarios would be great and sending > the acceptor's error token is the correct way to achieve that.) > > [...] > > Alternatively the draft could be modified in a > non-backwards compatible manner, but I believe it's too for that. That should read "... but I believe it's too late for that." > > [...] > Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 14:18:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00475 for ; Mon, 18 Nov 2002 14:17:59 -0500 (EST) Received: (qmail 13577 invoked by uid 605); 18 Nov 2002 19:20:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13569 invoked from network); 18 Nov 2002 19:20:31 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 18 Nov 2002 19:20:31 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05153; Mon, 18 Nov 2002 12:20:31 -0700 (MST) Received: from soe-austin.central.sun.com (niaus08.Central.Sun.COM [129.153.128.126]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIJKUOq025081; Mon, 18 Nov 2002 12:20:31 -0700 (MST) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAIJKUiU028896; Mon, 18 Nov 2002 13:20:30 -0600 (CST) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6/Submit) id gAIJKUVg028895; Mon, 18 Nov 2002 13:20:30 -0600 (CST) Date: Mon, 18 Nov 2002 13:20:30 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021118132029.D22254@soe-austin.central.sun.com> References: <20021118111613.A22254@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhutz@cmu.edu on Mon, Nov 18, 2002 at 01:36:33PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Nov 18, 2002 at 01:36:33PM -0500, Jeffrey Hutzelman wrote: > On Mon, 18 Nov 2002, Nicolas Williams wrote: [...] > Sorry; I guess I was unclear. I have no problem with recommending that > the SSH_MSG_KEXGSS_CONTINUE message be used to send error back error > tokens, provided that the party sending the error token (which, I believe, > could be the initiator or acceptor) remembers that it is in an error state > and does not then allow key exchange to succeed. Ah. Good. Then there is no disagreement. See below. > I only oppose dropping the SSH_MSG_KEXGSS_ERROR message, which I believe > provides useful debugging information that may not be available any other > way -- particularly if the mechanism in use does not generate interesting > error tokens. My reading of the GSS-API RFCs is that both sides of a context setup token exchange should be "synchronized," as it were, in that neither side should produce an output token-less status when the other side still expects a token (i.e., had GSS_S_CONTINUE_NEEDED). The specs do allow for one side to complete and then receive an unexpected error token from the other side that was not expected (thus the spec provides GSS_Process_context_token()). Nothing else makes sense. It would not be good for both sides to both produce GSS_S_CONTINUE_NEEDED but both also produce no output tokens, for example. I don't think that the protocol using GSS-API ought to send messages saying "[still] waiting for your token" unless GSS-API explicitly allowed for such deadlocks which could then only be detected and broken with "waiting for your token" messages defined by the application using GSS-API. So I think that we should never see a situation, no matter what the mechanism, where GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED and GSS_Accept_sec_context() returns a failure and no output error token, as this should generally lead to the initiator "hanging." Consider the gss-sample that comes with MIT krb5. (Gotta go check the SPKM/LIPKEY mech RFCs...). > All of the relevant messages should be optional or recommended, and we > should be consistent about it. See the last paragraph of the security > considerations section, in which we recommend that it be possible to > configure servers _not_ to send the error message, in order to avoid > giving an attacker information that may help him to break in. I don't think not sending a GSS error token should be optional, under any circumstance, unless the alternative is to close the connection without further ado. I do agree that SSH_MSG_KEXGSS_ERROR should be optional, if it even exist. The complete/continue_needed messages must be required though. [...] > You're right; we did fail to understand that. We understand it now, and > we can certainly add text to address the issue of error tokens, since it > seems the right thing to do is not entirely obvious. This is not > surprising, since the GSSAPI specs are notoriously difficult to fully > understand. I agree. E.g., see above - I'm not sure I can "prove" my contention that GSS mechs must be "synchronized" internally, not anymore than I could "prove" that GSS error tokens exist... If those RFCs are ever updated there's several items that need clarification - here we have two. > > Having SSH_MSG_KEXGSS_ERROR as a debug message is fine, but it will > > still only help when the client and server are of similar origins > > (meaning that they share definitions for the minor status codes of their > > supported mechanisms). This limited utility makes SSH_MSG_KEXGSS_ERROR > > less than useful, and, given that sending GSS error tokens interoperably > > provides the relevant information to the client anyways I see no reason > > to bother with SSH_MSG_KEXGSS_ERROR and its userauth friend. > > I disagree. The intent was never that the client would attempt to > interpret the status codes, but that it would display them to the user > (possibly only if an appropriate debugging option is enabled). When a > user says "I tried to ssh into your machine and it didn't work", being > able to get them to report the status codes can be quite useful -- > especially given that users are likely to report a code accurately when > they would attempt to interpret the meaning of a message. Why couldn't this be accomplished with debug messages on the server side? Or with the server sending debug messages to the client? (there's no debug messages during key exchange, are there?) Regardless, the draft should be clear that the minor status code is implementation specific and that the client should not attempt to interpret it (the message in question has a field for a human readable error message string anyways). > > > > - SSH_MSG_KEXGSS_CONTINUE should continue to be used as specified in > > > > the draft > > > > > > > > - SSH_MSG_KEXGSS_CONTINUE should also be used to send any GSS "error" > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > tokens > > ^^^^^^^^^^^^^ > > > > Do you object to this? This is the actual, backwards compatible draft > > change needed to have interoperable communications about GSS errors. > > For clarity: No, I do not object to this. Cool. Problem solved. > -- Jeff > Thanks, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 15:59:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03256 for ; Mon, 18 Nov 2002 15:59:27 -0500 (EST) Received: (qmail 27815 invoked by uid 605); 18 Nov 2002 21:02:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27808 invoked from network); 18 Nov 2002 21:02:00 -0000 Received: from liandra.ietf55.ops.ietf.org (HELO liandra.pc.cs.cmu.edu) (204.42.65.139) by mail.netbsd.org with SMTP; 18 Nov 2002 21:02:00 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa10133; 18 Nov 2002 16:01 EST Date: Mon, 18 Nov 2002 16:01:49 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSHv2 GSS spec issue wrt gss error tokens In-Reply-To: <20021118132029.D22254@soe-austin.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > I don't think not sending a GSS error token should be optional, under > any circumstance, unless the alternative is to close the connection > without further ado. Effectively, that is the alternative. If there is an error, the server sends up to three messages: - optional SSH_MSG_KEXGSS_CONTINUE with the error token - optional SSH_MSG_KEXGSS_ERROR with error status and message - recommended SSH_MSG_DISCONNECT with SSH_DISCONNECT_KEY_EXCHANGE_FAILED. - close the connection For user auth the exchange is slightly different: - optional SSH_MSG_USERAUTH_GSSAPI_TOKEN with the error token - optional SSH_MSG_USERAUTH_GSSAPI_ERROR with error status and message - required SSH_MSG_USERAUTH_FAILURE Once the client receives SSH_MSG_USERAUTH_FAILURE, it aborts the GSSAPI exchange and may either close the connection or try again. > Why couldn't this be accomplished with debug messages on the server > side? Or with the server sending debug messages to the client? (there's > no debug messages during key exchange, are there?) I don't see anything specific that prohibits debug messages during key exchange. However, the use of a separate "error" message makes it clear that we are describing the reason for an error, which could have an effect on whether the client displays the result to the user (for example, the client may choose to try multiple user auth methods, and only display the error information if all fail). > Regardless, the draft should be clear that the minor status code is > implementation specific and that the client should not attempt to > interpret it (the message in question has a field for a human readable > error message string anyways). Yes, I agree we should add some clarifying text. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 16:04:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03438 for ; Mon, 18 Nov 2002 16:04:57 -0500 (EST) Received: (qmail 1212 invoked by uid 605); 18 Nov 2002 21:07:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1203 invoked from network); 18 Nov 2002 21:07:31 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 18 Nov 2002 21:07:31 -0000 Received: from softhome.net (unknown [200.71.8.80]) by narn.netbsd.org (Postfix) with SMTP id 3013C11122 for ; Mon, 18 Nov 2002 13:07:29 -0800 (PST) From: "Instituto Iberoamericano de Logistica" To: (La Sociedad Digital) Subject: Logistica- Curso de Distribucion Fisica. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 20 Nov 2002 05:51:15 -0300 Reply-To: "Instituto Iberoamericano de Logistica" Content-Transfer-Encoding: 8bit Message-Id: <20021118210729.3013C11122@narn.netbsd.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit El Instituto Iberoamericano de Logistica, Transporte y Comercio Internacional tiene el agrado de anunciar la realizacion del Curso de Distribucion Fisica, equivalente al Modulo III del Diploma de Experto en Logistica de este Instituto y el Instituto Catalan de Logistica de la Universidad Politecnica de Cataluña. El mismo, cuyo programa se detalla a continuacion se llevara a cabo en el local central del Instituto, en Sarandi 637 Piso 2 de Montevideo, desde el 25 al 29 de noviembre de 2002 en el horario de 18.30 a 22.30. Consultas e inscripciones, con el Sr. Eduardo, de lunes a viernes de 09.oo a 13.oo horas por los telefonos 9166034 / 9166098 o bien por el correo electronico ilimont@softhome.net CURSO DE DISTRIBUCION FISICA - MODULO III DEL DIPLOMA DE EXPERTO EN LOGÍSTICA * METODOLOGIA ACTIVA Y PARTICIPATIVA, CON LA COMBINACIÓN DE EXPOSICIONES TÉCNICAS, ESTUDIO DE CASOS Y RECURSOS AUDIOVISUALES. * TITULACION MODULO EXPEDIDO POR ILI E ICIL, QUE GENERARÁ CRÉDITOS PARA EL DIPLOMA DE EXPERTO EN LOGÍSTICA. LA TITULACIÓN ES DE DOS TIPOS: CERTIFICADO DE ASISTENCIA, COMPLETANDO EL 90% DEL TIEMPO LECTIVO Y POSIBILIDAD DE RENDIR PRUEBA FINAL A FIN DEL CURSO, CUYA APROBACIÓN GENERA CRÉDITOS PARA LA OBTENCIÓN DEL DIPLOMA DE EXPERTO EN LOGÍSITCA. * DURACIÓN CADA MODULO ES DE 20 HORAS LECTIVAS * OBJETIVO DEL MODULO: La distribución física es una de las áreas estratégicas para conseguir una mejor calidad de servicios al cliente y de diferenciación de la empresa. El objetivo del curso es facilitar esos conocimientos y los medios para obtener los resultados óptimos en la gestión del área. * DESTINATARIOS: Dirigido a los profesionales con responsabilidades en el área de la distribución física de las empresas o los directores de gestión de las empresas de distribución que están directamente interesados en los contenidos de este curso. * CONTENIDO GENERAL: La reingeniería actual de la distribución física: supply management Sistemas y diseño de la distribución física Manipulación y almacenaje La gestión del transporte Control economico de la gestión de distribución física. Puede solicitarse un programa analitico a ilimont@softhome.net Agradecemos su atencion y, si por algun motivo no desea continuar recibiendo la informacion del Instituto, rogamos se sirva enviar un mail con el subject "remove" a ilimont@softhome.net. Muchas gracias. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 16:56:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04969 for ; Mon, 18 Nov 2002 16:56:50 -0500 (EST) Received: (qmail 25129 invoked by uid 605); 18 Nov 2002 21:59:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25118 invoked from network); 18 Nov 2002 21:59:24 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 18 Nov 2002 21:59:24 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20879; Mon, 18 Nov 2002 14:59:23 -0700 (MST) Received: from soe-austin.central.sun.com (niaus08.Central.Sun.COM [129.153.128.126]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAILxN1i027855; Mon, 18 Nov 2002 14:59:23 -0700 (MST) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAILxMiU006348; Mon, 18 Nov 2002 15:59:22 -0600 (CST) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6/Submit) id gAILxLZO006347; Mon, 18 Nov 2002 15:59:21 -0600 (CST) Date: Mon, 18 Nov 2002 15:59:21 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021118155921.E22254@soe-austin.central.sun.com> References: <20021118132029.D22254@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhutz@cmu.edu on Mon, Nov 18, 2002 at 04:01:49PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Ok, one more go around: On Mon, Nov 18, 2002 at 04:01:49PM -0500, Jeffrey Hutzelman wrote: > > I don't think not sending a GSS error token should be optional, under > > any circumstance, unless the alternative is to close the connection > > without further ado. > > Effectively, that is the alternative. If there is an error, the server > sends up to three messages: > > - optional SSH_MSG_KEXGSS_CONTINUE with the error token Why is this optional? (To provide for error obfuscation?) It should be recommended, not merely optional. BTW, GSS-API ought to provide a feature for error token obfuscation. Better to let the mechanism determine what error information to send than to let the GSS application get away with not sending error tokens. In the meantime, I'd agree to making SSH_MSG_KEXGSS_CONTINUE w/ error tokens optional, but recommended - SHOULD, in fact, and the error code shrouding rationale should be described in the security considerations section, say. That brings up another question: do the various SSHv2 drafts consistently provide for error code obfuscation where errors are sent on the wire? Should GSS-keyex be consistent with the other SSHv2 drafts on this? > - optional SSH_MSG_KEXGSS_ERROR with error status and message > - recommended SSH_MSG_DISCONNECT with SSH_DISCONNECT_KEY_EXCHANGE_FAILED. > - close the connection > > > For user auth the exchange is slightly different: > - optional SSH_MSG_USERAUTH_GSSAPI_TOKEN with the error token > - optional SSH_MSG_USERAUTH_GSSAPI_ERROR with error status and message > - required SSH_MSG_USERAUTH_FAILURE > > Once the client receives SSH_MSG_USERAUTH_FAILURE, it aborts the GSSAPI > exchange and may either close the connection or try again. > > > Why couldn't this be accomplished with debug messages on the server > > side? Or with the server sending debug messages to the client? (there's > > no debug messages during key exchange, are there?) > > I don't see anything specific that prohibits debug messages during key > exchange. However, the use of a separate "error" message makes it clear > that we are describing the reason for an error, which could have an effect > on whether the client displays the result to the user (for example, the > client may choose to try multiple user auth methods, and only display the > error information if all fail). Ok. > > Regardless, the draft should be clear that the minor status code is > > implementation specific and that the client should not attempt to > > interpret it (the message in question has a field for a human readable > > error message string anyways). > > Yes, I agree we should add some clarifying text. Thanks. > -- Jeff > Thanks, Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 17:13:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05599 for ; Mon, 18 Nov 2002 17:13:14 -0500 (EST) Received: (qmail 3890 invoked by uid 605); 18 Nov 2002 22:15:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3883 invoked from network); 18 Nov 2002 22:15:49 -0000 Received: from liandra.ietf55.ops.ietf.org (HELO liandra.pc.cs.cmu.edu) (204.42.65.139) by mail.netbsd.org with SMTP; 18 Nov 2002 22:15:49 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa10242; 18 Nov 2002 17:15 EST Date: Mon, 18 Nov 2002 17:15:33 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSHv2 GSS spec issue wrt gss error tokens In-Reply-To: <20021118155921.E22254@soe-austin.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 18 Nov 2002, Nicolas Williams wrote: > Why is this optional? (To provide for error obfuscation?) It should be > recommended, not merely optional. Yes, that's the idea. We can argue about which messages should be recommended vs optional. I'm inclined to make sending the error token via a continue message recommended but not required, and make the error message optional. > BTW, GSS-API ought to provide a feature for error token obfuscation. > Better to let the mechanism determine what error information to send > than to let the GSS application get away with not sending error tokens. Not necessarily. The application may be in a much better position to detect an ongoing attack than is the GSSAPI mechanism. In any event, the GSSAPI currently does not have such a feature, and this is not the forum in which to discuss fixing GSSAPI. > That brings up another question: do the various SSHv2 drafts > consistently provide for error code obfuscation where errors are sent on > the wire? Should GSS-keyex be consistent with the other SSHv2 drafts on > this? I think if you read over the drafts, you'll find that in most cases, no mechanism is provided for passing specific error information back. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 18 17:26:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05929 for ; Mon, 18 Nov 2002 17:26:19 -0500 (EST) Received: (qmail 10074 invoked by uid 605); 18 Nov 2002 22:28:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10067 invoked from network); 18 Nov 2002 22:28:54 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 18 Nov 2002 22:28:54 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11832; Mon, 18 Nov 2002 15:28:54 -0700 (MST) Received: from soe-austin.central.sun.com (niaus08.Central.Sun.COM [129.153.128.126]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIMSr1i006247; Mon, 18 Nov 2002 15:28:53 -0700 (MST) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAIMSqiU006999; Mon, 18 Nov 2002 16:28:52 -0600 (CST) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.6+Sun/8.12.6/Submit) id gAIMSqXF006998; Mon, 18 Nov 2002 16:28:52 -0600 (CST) Date: Mon, 18 Nov 2002 16:28:52 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: SSHv2 GSS spec issue wrt gss error tokens Message-ID: <20021118162852.H22254@soe-austin.central.sun.com> References: <20021118155921.E22254@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhutz@cmu.edu on Mon, Nov 18, 2002 at 05:15:33PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Nov 18, 2002 at 05:15:33PM -0500, Jeffrey Hutzelman wrote: > On Mon, 18 Nov 2002, Nicolas Williams wrote: > > > Why is this optional? (To provide for error obfuscation?) It should be > > recommended, not merely optional. > > Yes, that's the idea. We can argue about which messages should be > recommended vs optional. I'm inclined to make sending the error token via > a continue message recommended but not required, and make the error > message optional. Ok. I vote for recommended (SHOULD). A note should be made about not sending error tokens for error obfuscation. > > BTW, GSS-API ought to provide a feature for error token obfuscation. > > Better to let the mechanism determine what error information to send > > than to let the GSS application get away with not sending error tokens. > > Not necessarily. The application may be in a much better position to > detect an ongoing attack than is the GSSAPI mechanism. In any event, the > GSSAPI currently does not have such a feature, and this is not the forum > in which to discuss fixing GSSAPI. Indeed. I mentioned that apropos the subject in question. Arguably the fact that GSS-API does not provide for error obfuscation does not license applications to violate the spirit and letter of the GSS specs. That said this is a minor, tolerable violation, provided it is intentional (thus my vote for recommending that error tokens be sent). > > That brings up another question: do the various SSHv2 drafts > > consistently provide for error code obfuscation where errors are sent on > > the wire? Should GSS-keyex be consistent with the other SSHv2 drafts on > > this? > > I think if you read over the drafts, you'll find that in most cases, no > mechanism is provided for passing specific error information back. Yeah, ok. Thanks, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 21 06:52:52 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28666 for ; Thu, 21 Nov 2002 06:52:52 -0500 (EST) Received: (qmail 13523 invoked by uid 605); 21 Nov 2002 11:54:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13513 invoked from network); 21 Nov 2002 11:54:14 -0000 Received: from 213-96-83-91.uc.nombres.ttd.es (HELO correo.techgeo.es) (213.96.83.91) by mail.netbsd.org with SMTP; 21 Nov 2002 11:54:14 -0000 Received: from mail.Zapo.Net ([67.234.73.91]) by correo.techgeo.es (Lotus Domino Release 5.0.9) with ESMTP id 2002112111123116:3633 ; Thu, 21 Nov 2002 11:12:31 +0100 Message-ID: <000075862d76$00005405$00001786@mail.Zapo.Net> To: From: "Damascus" Subject: Award Winning TiNives 5th Year Anniversary 20% Savings Date: Thu, 21 Nov 2002 04:12:30 -1800 MIME-Version: 1.0 Reply-To: Knives@Zapo.Net X-Priority: 3 (Normal) X-MSMail-Priority: Normal MIME-Version: 1.0 X-Mailer: Microsoft Outlook, Build 10.0.2616 Sensitivity: Private X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on SVRTECHGEO/CERT(Release 5.0.9 |November 16, 2001) at 21/11/2002 11.12.32, Serialize by Router on SVRTECHGEO/CERT(Release 5.0.9 |November 16, 2001) at 21/11/2002 12.54.17, Serialize complete at 21/11/2002 12.54.17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="Windows-1252" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit
TiNives Custom Shop provides specialty handle coatings, inlay of preciuos metals, and titanium contoured handles with a variety of texturing. Blade material consist of an assortment of Devin Thomas damascus, Damasteel damascus, 154 CM (option for black diamond coating).
Visit Us at: www.tinives.com
Offer Expires December 30, 2002. Offer not available with other discounts.

From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 21 20:41:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00711 for ; Thu, 21 Nov 2002 20:41:06 -0500 (EST) Received: (qmail 9842 invoked by uid 605); 22 Nov 2002 01:43:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9835 invoked from network); 22 Nov 2002 01:43:38 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 22 Nov 2002 01:43:38 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 831FE529A; Fri, 22 Nov 2002 02:43:37 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 46B351DF6; Fri, 22 Nov 2002 02:43:30 +0100 (MET) Date: Thu, 21 Nov 2002 20:42:38 -0500 (EST) From: Jakob Schlyter To: IETF Secure Shell WG Cc: Wesley Griffin Subject: draft-ietf-secsh-dns-{01,02} diff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list upcoming changes for -02. seems reasonable? We know of no other outstanding issues. jakob & wes Index: draft-ietf-secsh-dns-xx.xml =================================================================== RCS file: /cvs/sshdev/draft/draft-ietf-secsh-dns-xx.xml,v retrieving revision 1.34 retrieving revision 1.38 diff -u -r1.34 -r1.38 --- draft-ietf-secsh-dns-xx.xml 3 Nov 2002 13:51:08 -0000 1.34 +++ draft-ietf-secsh-dns-xx.xml 21 Nov 2002 16:13:45 -0000 1.38 @@ -1,13 +1,13 @@ - + - + Using DNS to securely @@ -118,11 +118,20 @@ <section anchor="policy" title="Implementation notes"> <t> - Client implementors SHOULD to provide a configurable policy used + Client implementors SHOULD provide a configurable policy used to select the order of methods used to verify a host key and which fingerprints to trust ultimately, after user confirmation or not at all. </t> + <t> + One specific scenario for having a configurable policy is where + clients use unqualified host names to connect to servers. In this + scenario, the implmentation SHOULD verify the host key against a + local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from + injecting a DNS search path into the local resolver and forcing + the client to connect to a different host. + </t> </section> <section title="Fingerprint matching"> @@ -354,15 +363,12 @@ <back> - <references> + <references title="Normative References"> + <?rfc include="reference.RFC.1034.xml"?> <?rfc include="reference.RFC.1035.xml"?> <?rfc include="reference.RFC.2119.xml"?> - <?rfc include="reference.RFC.2411.xml"?> <?rfc include="reference.RFC.2535.xml"?> - <?rfc include="reference.RFC.2845.xml"?> - <?rfc include="reference.RFC.2931.xml"?> - <?rfc include="reference.RFC.3007.xml"?> <reference anchor="ssh-architecture"> <front> @@ -415,6 +421,15 @@ <seriesInfo name="work in progress" value="draft-ietf-secsh-transport-15.txt"/> </reference> + + </references> + + <references title="Informational References"> + + <?rfc include="reference.RFC.2411.xml"?> + <?rfc include="reference.RFC.2845.xml"?> + <?rfc include="reference.RFC.2931.xml"?> + <?rfc include="reference.RFC.3007.xml"?> </references> From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 21 20:54:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01249 for <secsh-archive@odin.ietf.org>; Thu, 21 Nov 2002 20:54:04 -0500 (EST) Received: (qmail 15115 invoked by uid 605); 22 Nov 2002 01:56:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15108 invoked from network); 22 Nov 2002 01:56:41 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 22 Nov 2002 01:56:41 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19258 for <ietf-ssh@netbsd.org>; Thu, 21 Nov 2002 17:56:40 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM1ue9x028645 for <ietf-ssh@netbsd.org>; Thu, 21 Nov 2002 20:56:40 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gAM1uefR004310 for <ietf-ssh@netbsd.org>; Thu, 21 Nov 2002 20:56:40 -0500 (EST) Message-Id: <200211220156.gAM1uefR004310@thunk.east.sun.com> From: Bill Sommerfeld <sommerfeld@sun.com> To: ietf-ssh@netbsd.org Subject: churn, churn, churn Reply-to: sommerfeld@sun.com Date: Thu, 21 Nov 2002 20:56:40 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Latest nit from the AD's on core documents: need to separate normative and non-normative references, per http://www.rfc-editor.org/policy.html I'd appreciate it if a couple people could play "spot the non-normative references" in the current drafts and share their results with me and/or the WG. (I've done a quick look myself; the vast majority are normative). There will be a document re-spin after this exercise. Thank you for your assistance. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 25 04:29:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23204 for <secsh-archive@odin.ietf.org>; Mon, 25 Nov 2002 04:29:27 -0500 (EST) Received: (qmail 5681 invoked by uid 605); 25 Nov 2002 09:31:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5674 invoked from network); 25 Nov 2002 09:31:48 -0000 Received: from unknown (HELO tparelay.telradnetworks.co.il) (62.90.58.229) by mail.netbsd.org with SMTP; 25 Nov 2002 09:31:48 -0000 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.5/8.12.5) with ESMTP id gAP9UrBx029869 for <ietf-ssh@netbsd.org>; Mon, 25 Nov 2002 11:30:53 +0200 (IST) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.5/8.12.5) with ESMTP id gAP9UpnO029865 for <ietf-ssh@netbsd.org>; Mon, 25 Nov 2002 11:30:51 +0200 (IST) Received: by tpa-mail1.Telrad.co.il with Internet Mail Service (5.5.2654.89) id <W784K8WJ>; Mon, 25 Nov 2002 11:30:56 +0200 Message-ID: <E20C627AB7F6D4118C4200508BB3C49A045DF830@tpa-mail1.Telrad.co.il> From: Dan Davidson <dan.davidson@commatch.com> To: ietf-ssh@netbsd.org Subject: Filexfer version 3 vs. Filexfer version 4 Date: Mon, 25 Nov 2002 11:30:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="windows-1255" Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, The version 4 of the SSH File Transfer Protocol strictly forbids the transmission of extensions in the SSH_FXP_INIT packet. However, it may happen that a version 3 Client initiating a connection towards a version 4 Server will send such extensions in the INIT message. What behavior is expected from the Server in such a case ? Thanks and best regards, Dan From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 25 09:12:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28860 for <secsh-archive@odin.ietf.org>; Mon, 25 Nov 2002 09:12:52 -0500 (EST) Received: (qmail 28439 invoked by uid 605); 25 Nov 2002 14:14:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28388 invoked from network); 25 Nov 2002 14:14:31 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 25 Nov 2002 14:14:31 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <W1LKVZ1A>; Mon, 25 Nov 2002 09:14:29 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA838@lespaul.process.com> From: Richard Whalen <Whalenr@process.com> To: ietf-ssh@netbsd.org Subject: RE: Filexfer version 3 vs. Filexfer version 4 Date: Mon, 25 Nov 2002 09:14:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Dan Davidson [mailto:dan.davidson@commatch.com] > Sent: Monday, November 25, 2002 4:31 AM > To: ietf-ssh@netbsd.org > Subject: Filexfer version 3 vs. Filexfer version 4 > > > Hi, > > The version 4 of the SSH File Transfer Protocol > strictly forbids the > transmission > of extensions in the SSH_FXP_INIT packet. > However, it may happen that a version 3 Client initiating a connection > towards a version 4 Server > will send such extensions in the INIT message. > > What behavior is expected from the Server in such a case ? > > Thanks and best regards, > Dan > > I believe that this depends upon the server. If the server "supports" V3 as well as V4, then it should process the extension information. If it only supports V4, then it would be reasonable to ignore the entire message as it is ill-formed and there is no error response to the SSH_FXP_INIT packet. The extensions were removed from the SSH_FXP_INIT packet as their presence can cause problems when a V3 client sends them to a V2 server. ---------------------- Richard Whalen Process Software 508-879-6994x261 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 25 16:40:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27048 for <secsh-archive@odin.ietf.org>; Mon, 25 Nov 2002 16:40:12 -0500 (EST) Received: (qmail 10932 invoked by uid 605); 25 Nov 2002 21:42:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10916 invoked from network); 25 Nov 2002 21:42:38 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 25 Nov 2002 21:42:38 -0000 Received: from [127.0.0.1] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1034958 for ietf-ssh@netbsd.org; Mon, 25 Nov 2002 14:42:36 -0700 Message-ID: <001601c294cb$45904570$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" <galb-list@vandyke.com> To: <ietf-ssh@netbsd.org> Subject: New draft-draft of sftp... Date: Mon, 25 Nov 2002 14:40:28 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C29490.9901D1F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C29490.9901D1F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Greetings, Here, is a new draft-draft of the sftp draft. Changes are a little bit more extensive than I remembered at the meeting: o Copied more NFS to clarify ACLs and reserved identifiers for the ACL who field. Thanks Richard. (I may need to do one more round of this-- in the context of normative vs. non-normative, I would prefer our NFS references to be non-normative, which means we have to included sufficient information to stand alone. Probably a good idea anyway.) o Change times to be 64 bit + 32 bit nanosecond field (as per decision at meeting and NFS.) o Added additional optional extension to allow the server to tell the client that it compares files in a case insensitive way, or that files are stored in a case insensitive way. Since globbing is done on the client, the client needs this information to "get it right". In the absence of the extension, client is to assume 'case sensitive'. I would like to make one more change that I know of: o add a bit to the type field to flag whether the file should be hidden. Under most unixes files beginning with a '.' should be hidden. Windows represents this with an attribute bit. So, only the server can really tell whether a given file should be hidden (by default) or not. If people are okay with this I will make this change and submit. We are in a hurry here because we want to get this out before we have implementers so that we don't have to rev the version field again. Are any of the unix implementers out there looking at this revision any time soon? As I mentioned at the working group meeting, I would like to have a unix implementation to make sure we have made things onerous for unix / posixish systems. Thanks, Joseph ------=_NextPart_000_0013_01C29490.9901D1F0 Content-Type: text/plain; name="draft-ietf-secsh-filexfer.txt" Content-Disposition: attachment; filename="draft-ietf-secsh-filexfer.txt" Content-Transfer-Encoding: quoted-printable Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: April 1, 2003 T. Ylonen S. Lehtinen SSH Communications Security Corp October 2002 SSH File Transfer Protocol draft-ietf-secsh-filexfer-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract 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. Galbraith, et al. Expires April 1, 2003 [Page 1] =0C Internet-Draft SSH File Transfer Protocol October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use with the SSH Connection Protocol . . . . . . . . . . . 4 3. General Packet Format . . . . . . . . . . . . . . . . . . 5 4. Protocol Initialization . . . . . . . . . . . . . . . . . 7 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 7 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 7 4.3 Determining Server Newline Convention . . . . . . . . . . 8 4.4 Case sensitivity on the server . . . . . . . . . . . . . . 9 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 10 5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 11 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 14 6. Requests From the Client to the Server . . . . . . . . . . 15 6.1 Request Synchronization and Reordering . . . . . . . . . . 15 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 16 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 19 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 20 6.6 Creating and Deleting Directories . . . . . . . . . . . . 21 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 21 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 22 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 23 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 24 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 25 6.11.1 Best practice for dealing with paths . . . . . . . . . . . 25 7. Responses from the Server to the Client . . . . . . . . . 26 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . 31 10. Changes from previous protocol versions . . . . . . . . . 32 10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 32 10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 32 10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 33 10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 33 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 34 References . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 Full Copyright Statement . . . . . . . . . . . . . . . . . 37 Galbraith, et al. Expires April 1, 2003 [Page 2] =0C Internet-Draft SSH File Transfer Protocol October 2002 1. Introduction This protocol provides secure file transfer (and more generally file system access) functionality over a reliable data stream, such as a channel in the SSH2 protocol [5]. This protocol is designed so that it could be used to implement a secure remote file system service, as well as a secure file transfer service. This protocol assumes that it runs over a secure channel, and that the server has already authenticated the user at the client end, and that the identity of the client user is externally available to the server implementation. In general, this protocol follows a simple request-response model. Each request and response contains a sequence number and multiple requests may be pending simultaneously. There are a relatively large number of different request messages, but a small number of possible response messages. Each request has one or more response messages that may be returned in result (e.g., a read either returns data or reports error status). The packet format descriptions in this specification follow the notation presented in the secsh architecture draft. [5] Even though this protocol is described in the context of the SSH2 protocol, this protocol is general and independent of the rest of the SSH2 protocol suite. It could be used in a number of different applications, such as secure file transfer over TLS RFC 2246 [1] and transfer of management information in VPN applications. Galbraith, et al. Expires April 1, 2003 [Page 3] =0C Internet-Draft SSH File Transfer Protocol October 2002 2. Use with the SSH Connection Protocol When used with the SSH2 Protocol suite, this protocol is intended to be used from the SSH Connection Protocol [7] as a subsystem, as described in section ``Starting a Shell or a Command''. The subsystem name used with this protocol is "sftp". Galbraith, et al. Expires April 1, 2003 [Page 4] =0C Internet-Draft SSH File Transfer Protocol October 2002 3. General Packet Format All packets transmitted over the secure connection are of the following format: uint32 length byte type byte[length - 1] data payload That is, they are just data preceded by 32-bit length and 8-bit type fields. The `length' is the length of the data area, and does not include the `length' field itself. The format and interpretation of the data area depends on the packet type. All packet descriptions below only specify the packet type and the data that goes into the data field. Thus, they should be prefixed by the `length' and `type' fields. The maximum size of a packet is in practice determined by the client (the maximum size of read or write requests that it sends, plus a few bytes of packet overhead). All servers SHOULD support packets of at least 34000 bytes (where the packet size refers to the full length, including the header above). This should allow for reads and writes of at most 32768 bytes. There is no limit on the number of outstanding (non-acknowledged) requests that the client may send to the server. In practice this is limited by the buffering available on the data stream and the queuing performed by the server. If the server's queues are full, it should not read any more data from the stream, and flow control will prevent the client from sending more requests. Note, however, that while there is no restriction on the protocol level, the client's API may provide a limit in order to prevent infinite queuing of outgoing requests at the client. The following values are defined for packet types. Galbraith, et al. Expires April 1, 2003 [Page 5] =0C Internet-Draft SSH File Transfer Protocol October 2002 #define SSH_FXP_INIT 1 #define SSH_FXP_VERSION 2 #define SSH_FXP_OPEN 3 #define SSH_FXP_CLOSE 4 #define SSH_FXP_READ 5 #define SSH_FXP_WRITE 6 #define SSH_FXP_LSTAT 7 #define SSH_FXP_FSTAT 8 #define SSH_FXP_SETSTAT 9 #define SSH_FXP_FSETSTAT 10 #define SSH_FXP_OPENDIR 11 #define SSH_FXP_READDIR 12 #define SSH_FXP_REMOVE 13 #define SSH_FXP_MKDIR 14 #define SSH_FXP_RMDIR 15 #define SSH_FXP_REALPATH 16 #define SSH_FXP_STAT 17 #define SSH_FXP_RENAME 18 #define SSH_FXP_READLINK 19 #define SSH_FXP_SYMLINK 20 #define SSH_FXP_STATUS 101 #define SSH_FXP_HANDLE 102 #define SSH_FXP_DATA 103 #define SSH_FXP_NAME 104 #define SSH_FXP_ATTRS 105 #define SSH_FXP_EXTENDED 200 #define SSH_FXP_EXTENDED_REPLY 201 RESERVED_FOR_EXTENSIONS 210-255 Additional packet types should only be defined if the protocol version number (see Section ``Protocol Initialization'') is incremented, and their use MUST be negotiated using the version number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY packets can be used to implement vendor-specific extensions. See Section ``Vendor-Specific-Extensions'' for more details. Galbraith, et al. Expires April 1, 2003 [Page 6] =0C Internet-Draft SSH File Transfer Protocol October 2002 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. The version number of the protocol specified in this document is 4. The version number should be incremented for each incompatible revision of this protocol. 4.1 Client Initialization The SSH_FXP_INIT packet (from client to server) has the following data: uint32 version Version 3 of this protocol allowed clients to include extensions in the SSH_FXP_INIT packet; however, this can cause interoperability problems with version 1 and version 2 servers because the client must send this packet before knowing the servers version. In this version of the protocol, clients MUST use the SSH_FXP_EXTENDED packet to send extensions to the server after version exchange has completed. Clients MUST NOT include extensions in the version packet. This will prevent interoperability problems with older servers 4.2 Server Initialization The SSH_FXP_VERSION packet (from server to client) has the following data: uint32 version <extension data> 'version' is the lower of the protocol version supported by the server and the version number received from the client. The extension data may be empty, or may be a sequence of string extension_name string extension_data pairs (both strings MUST always be present if one is, but the `extension_data' string may be of zero length). If present, these Galbraith, et al. Expires April 1, 2003 [Page 7] =0C Internet-Draft SSH File Transfer Protocol October 2002 strings indicate extensions to the baseline protocol. The `extension_name' field(s) identify the name of the extension. The name should be of the form "name@domain", where the domain is the DNS domain name of the organization defining the extension. Additional names that are not of this format may be defined later by the IETF. Implementations MUST silently ignore any extensions whose name they do not recognize. 4.3 Determining Server Newline Convention In order to correctly process text files in a cross platform compatible way, the newline convention must be converted from that of the server to that of the client, or, during an upload, from that of the client to that of the server. Versions 3 and prior of this protocol made no provisions for processing text files. Many clients implemented some sort of conversion algorithm, but without either a 'canonical' on the wire format or knowledge of the servers newline convention, correct conversion was not always possible. Starting with Version 4, the SSH_FXF_TEXT file open flag (Section 6.3) makes it possible to request that the server translate a file to a 'canonical' on the wire format. This format uses \r\n as the line separator. Servers for systems using multiple newline characters (for example, Mac OS X or VMS) or systems using counted records, MUST translate to the canonical form. However, to ease the burden of implementation on servers that use a single, simple separator sequence, the following extension allows the canonical format to be changed. string "newline" string new-canonical-separator (usually "\r" or "\n" or "\r\n") All clients MUST support this extension. When processing text files, clients SHOULD NOT translate any character or sequence that is not an exact match of the servers newline separator. In particular, if the newline sequence being used is the canonical "\r\n" sequence, a lone \r or a lone \n SHOULD be written through without change. Galbraith, et al. Expires April 1, 2003 [Page 8] =0C Internet-Draft SSH File Transfer Protocol October 2002 4.4 Case sensitivity on the server In order for the client to preform accurate and consistent filename globbing, the client may need to know whether or not filenames on the server are case sensitive or not. The following extension allows the server to communicate information about how filenames are compared and stored. string "case-sensitive" byte case-flags The following flags are supported: #define SSH_FILEXFER_CASE_COMPARE 0x01 #define SSH_FILEXFER_CASE_STORE 0x02 If CASE_COMPARE is set, filename comparisons are case sensitive on the server, and two files with names differing only by case are typically two different files. If CASE_STORE is set, case is preserved when filenames are stored, and typically, adding a filename and then enumerating the directory will return the filename with no change of case. Clients MAY support this extension in order to provide improved behavior. In the absence of this extension, clients SHOULD assume that filename comparisions are case sensitive and that case is stored. Galbraith, et al. Expires April 1, 2003 [Page 9] =0C Internet-Draft SSH File Transfer Protocol October 2002 5. File Attributes A new compound data type is defined for encoding file attributes. The same encoding is used both when returning file attributes from the server and when sending file attributes to the server. When sending it to the server, the flags field specifies which attributes are included, and the server will use default values for the remaining attributes (or will not modify the values of remaining attributes). When receiving attributes from the server, the flags specify which attributes are included in the returned data. The server normally returns all attributes it knows about. uint32 flags byte type always present uint64 size present only if flag SIZE string owner present only if flag OWNERGROUP string group present only if flag OWNERGROUP uint32 permissions present only if flag PERMISSIONS uint64 atime present only if flag ACCESSTIME uint32 atime_nseconds present only if flag SUBSECOND_TIMES uint64 createtime present only if flag CREATETIME uint32 createtime_nseconds present only if flag SUBSECOND_TIMES uint64 mtime present only if flag MODIFYTIME uint32 mtime_nseconds present only if flag SUBSECOND_TIMES string acl present only if flag ACL uint32 extended_count present only if flag EXTENDED string extended_type string extended_data ... more extended data (extended_type - extended_data pairs), so that number of pairs equals extended_count 5.1 Flags The `flags' specify which of the fields are present. Those fields for which the corresponding flag is not set are not present (not included in the packet). New flags can only be added by incrementing the protocol version number (or by using the extension mechanism described below). The flags bits are defined to have the following values: Galbraith, et al. Expires April 1, 2003 [Page 10] =0C Internet-Draft SSH File Transfer Protocol October 2002 #define SSH_FILEXFER_ATTR_SIZE 0x00000001 #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000040 #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 #define SSH_FILEXFER_ATTR_ACL 0x00000040 #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 #define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100 #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 In previous versions of this protocol flags value 0x00000002 was SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP was given a new value in order to ease implementation burden. 0x00000002 MUST NOT appear in the mask. Some future version of this protocol may reuse flag 0x00000002. 5.2 Type The type field is always present. The following types are defined: #define SSH_FILEXFER_TYPE_REGULAR 1 #define SSH_FILEXFER_TYPE_DIRECTORY 2 #define SSH_FILEXFER_TYPE_SYMLINK 3 #define SSH_FILEXFER_TYPE_SPECIAL 4 #define SSH_FILEXFER_TYPE_UNKNOWN 5 On a POSIX system, these values would be derived from the permission field. 5.3 Size The `size' field specifies the size of the file on disk, in bytes. If it is present during file creation, it should be considered a hint as to the files eventual size. Files opened with the SSH_FXF_TEXT flag may have a size that is greater or less than the value of the size field. 5.4 Owner and Group The `owner' and `group' fields are represented as UTF-8 strings; this is the form used by NFS v4. See NFS version 4 Protocol. [3] The following text is selected quotations from section 5.6. To avoid a representation that is tied to a particular underlying implementation at the client or server, the use of UTF-8 strings has been chosen. The string should be of the form user@dns_domain". This will allow for a client and server that do not use the same Galbraith, et al. Expires April 1, 2003 [Page 11] =0C Internet-Draft SSH File Transfer Protocol October 2002 local representation the ability to translate to a common syntax that can be interpreted by both. In the case where there is no translation available to the client or server, the attribute value must be constructed without the "@". Therefore, the absence of the @ from the owner or owner_group attribute signifies that no translation was available and the receiver of the attribute should not place any special meaning with the attribute value. Even though the attribute value can not be translated, it may still be useful. In the case of a client, the attribute string may be used for local display of ownership. 5.5 Permissions The `permissions' field contains a bit mask of file permissions as defined by POSIX [1]. 5.6 Times The 'atime', 'createtime', and 'mtime' contain the access, creation, and modification times of the files, respectively. They are represented as seconds from Jan 1, 1970 in UTC. A negative value indicates number of seconds before Jan 1, 1970. In both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the nseconds field is to be added to the seconds field for the final time representation. For example, if the time to be represented is one- half second before 0 hour January 1, 1970, the seconds field would have a value of negative one (-1) and the nseconds fields would have a value of one-half second (500000000). Values greater than 999,999,999 for nseconds are considered invalid. 5.7 ACL The 'ACL' field contains an ACL similar to that defined in section 5.9 of NFS version 4 Protocol [3]. uint32 ace-count repeated ace-count time: uint32 ace-type uint32 ace-flag uint32 ace-mask string who [UTF-8] ace-type is one of the following four values (taken from NFS Version 4 Protocol [3]: Galbraith, et al. Expires April 1, 2003 [Page 12] =0C Internet-Draft SSH File Transfer Protocol October 2002 const ACE4_ACCESS_ALLOWED_ACE_TYPE =3D 0x00000000; const ACE4_ACCESS_DENIED_ACE_TYPE =3D 0x00000001; const ACE4_SYSTEM_AUDIT_ACE_TYPE =3D 0x00000002; const ACE4_SYSTEM_ALARM_ACE_TYPE =3D 0x00000003; ace-flag is a combination of the following flag values. See NFS Version 4 Protocol [3] section 5.9.2: const ACE4_FILE_INHERIT_ACE =3D 0x00000001; const ACE4_DIRECTORY_INHERIT_ACE =3D 0x00000002; const ACE4_NO_PROPAGATE_INHERIT_ACE =3D 0x00000004; const ACE4_INHERIT_ONLY_ACE =3D 0x00000008; const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG =3D 0x00000010; const ACE4_FAILED_ACCESS_ACE_FLAG =3D 0x00000020; const ACE4_IDENTIFIER_GROUP =3D 0x00000040; ace-mask is any combination of the following flags (taken from NFS Version 4 Protocol [3] section 5.9.3: const ACE4_READ_DATA =3D 0x00000001; const ACE4_LIST_DIRECTORY =3D 0x00000001; const ACE4_WRITE_DATA =3D 0x00000002; const ACE4_ADD_FILE =3D 0x00000002; const ACE4_APPEND_DATA =3D 0x00000004; const ACE4_ADD_SUBDIRECTORY =3D 0x00000004; const ACE4_READ_NAMED_ATTRS =3D 0x00000008; const ACE4_WRITE_NAMED_ATTRS =3D 0x00000010; const ACE4_EXECUTE =3D 0x00000020; const ACE4_DELETE_CHILD =3D 0x00000040; const ACE4_READ_ATTRIBUTES =3D 0x00000080; const ACE4_WRITE_ATTRIBUTES =3D 0x00000100; const ACE4_DELETE =3D 0x00010000; const ACE4_READ_ACL =3D 0x00020000; const ACE4_WRITE_ACL =3D 0x00040000; const ACE4_WRITE_OWNER =3D 0x00080000; const ACE4_SYNCHRONIZE =3D 0x00100000; who is a UTF-8 string of the form described in 'Owner and Group' (Section 5.4) Also, as per '5.9.4 ACE who' [3] there are several identifiers that need to be understood universally. Some of these identifiers cannot be understood when an client access the server, but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over SFTP. OWNER The owner of the file. Galbraith, et al. Expires April 1, 2003 [Page 13] =0C Internet-Draft SSH File Transfer Protocol October 2002 GROUP The group associated with the file. EVERYONE The world. INTERACTIVE Accessed from an interactive terminal. NETWORK Accessed via the network. DIALUP Accessed as a dialup user to the server. BATCH Accessed from a batch job. ANONYMOUS Accessed without any authentication. AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). SERVICE Access from a system service. To avoid conflict, these special identifiers are distinguish by an appended "@" and should appear in the form "xxxx@" (note: no domain name after the "@"). For example: ANONYMOUS@. 5.8 Extended attributes The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension mechanism for vendor-specific extensions. If the flag is specified, then the `extended_count' field is present. It specifies the number of extended_type-extended_data pairs that follow. Each of these pairs specifies an extended attribute. For each of the attributes, the extended_type field should be a string of the format "name@domain", where "domain" is a valid, registered domain name and "name" identifies the method. The IETF may later standardize certain names that deviate from this format (e.g., that do not contain the "@" sign). The interpretation of `extended_data' depends on the type. Implementations SHOULD ignore extended data fields that they do not understand. Additional fields can be added to the attributes by either defining additional bits to the flags field to indicate their presence, or by defining extended attributes for them. The extended attributes mechanism is recommended for most purposes; additional flags bits should only be defined by an IETF standards action that also increments the protocol version number. The use of such new fields MUST be negotiated by the version number in the protocol exchange. It is a protocol error if a packet with unsupported protocol bits is received. Galbraith, et al. Expires April 1, 2003 [Page 14] =0C Internet-Draft SSH File Transfer Protocol October 2002 6. Requests From the Client to the Server Requests from the client to the server represent the various file system operations. Each request begins with an `id' field, which is a 32-bit identifier identifying the request (selected by the client). The same identifier will be returned in the response to the request. One possible implementation is a monotonically increasing request sequence number (modulo 2^32). Many operations in the protocol operate on open files. The SSH_FXP_OPEN request can return a file handle (which is an opaque variable-length string) which may be used to access the file later (e.g. in a read operation). The client MUST NOT send requests the server with bogus or closed handles. However, the server MUST perform adequate checks on the handle in order to avoid security risks due to fabricated handles. This design allows either stateful and stateless server implementation, as well as an implementation which caches state between requests but may also flush it. The contents of the file handle string are entirely up to the server and its design. The client should not modify or attempt to interpret the file handle strings. The file handle strings MUST NOT be longer than 256 bytes. 6.1 Request Synchronization and Reordering The protocol and implementations MUST process requests relating to the same file in the order in which they are received. In other words, if an application submits multiple requests to the server, the results in the responses will be the same as if it had sent the requests one at a time and waited for the response in each case. For example, the server may process non-overlapping read/write requests to the same file in parallel, but overlapping reads and writes cannot be reordered or parallelized. However, there are no ordering restrictions on the server for processing requests from two different file transfer connections. The server may interleave and parallelize them at will. There are no restrictions on the order in which responses to outstanding requests are delivered to the client, except that the server must ensure fairness in the sense that processing of no request will be indefinitely delayed even if the client is sending other requests so that there are multiple outstanding requests all the time. Galbraith, et al. Expires April 1, 2003 [Page 15] =0C Internet-Draft SSH File Transfer Protocol October 2002 6.2 File Names This protocol represents file names as strings. File names are assumed to use the slash ('/') character as a directory separator. File names starting with a slash are "absolute", and are relative to the root of the file system. Names starting with any other character are relative to the user's default directory (home directory). Note that identifying the user is assumed to take place outside of this protocol. Servers SHOULD interpret a path name component ".." as referring to the parent directory, and "." as referring to the current directory. If the server implementation limits access to certain parts of the file system, it must be extra careful in parsing file names when enforcing such restrictions. There have been numerous reported security bugs where a ".." in a path name has allowed access outside the intended area. An empty path name is valid, and it refers to the user's default directory (usually the user's home directory). Otherwise, no syntax is defined for file names by this specification. Clients should not make any other assumptions; however, they can splice path name components returned by SSH_FXP_READDIR together using a slash ('/') as the separator, and that will work as expected. In order to comply with IETF Policy on Character Sets and Languages [2], all filenames are to be encoded in UTF-8. The shortest valid UTF-8 encoding of the UNICODE data MUST be used. The server is responsible for converting the UNICODE data to whatever canonical form it requires. For example, if the server requires that precomposed characters always be used, the server MUST NOT assume the filename as sent by the client has this attribute, but must do this normalization itself. It is understood that the lack of well-defined semantics for file names may cause interoperability problems between clients and servers using radically different operating systems. However, this approach is known to work acceptably with most systems, and alternative approaches that e.g. treat file names as sequences of structured components are quite complicated. 6.3 Opening, Creating, and Closing Files Files are opened and created using the SSH_FXP_OPEN message, whose data part is as follows: Galbraith, et al. Expires April 1, 2003 [Page 16] =0C Internet-Draft SSH File Transfer Protocol October 2002 uint32 id string filename [UTF-8] uint32 pflags ATTRS attrs The `id' field is the request identifier as for all requests. The `filename' field specifies the file name. See Section ``File Names'' for more information. The `pflags' field is a bitmask. The following bits have been defined. #define SSH_FXF_READ 0x00000001 #define SSH_FXF_WRITE 0x00000002 #define SSH_FXF_APPEND 0x00000004 #define SSH_FXF_CREAT 0x00000008 #define SSH_FXF_TRUNC 0x00000010 #define SSH_FXF_EXCL 0x00000020 #define SSH_FXF_TEXT 0x00000040 These have the following meanings: SSH_FXF_READ Open the file for reading. SSH_FXF_WRITE Open the file for writing. If both this and SSH_FXF_READ are specified, the file is opened for both reading and writing. SSH_FXF_APPEND Force all writes to append data at the end of the file. The offset parameter to write will be ignored. SSH_FXF_CREAT If this flag is specified, then a new file will be created if one does not already exist (if O_TRUNC is specified, the new file will be truncated to zero length if it previously exists). SSH_FXF_TRUNC Forces an existing file with the same name to be truncated to zero length when creating a file by specifying SSH_FXF_CREAT. SSH_FXF_CREAT MUST also be specified if this flag is used. SSH_FXF_EXCL Causes the request to fail if the named file already exists. SSH_FXF_CREAT MUST also be specified if this flag is used. Galbraith, et al. Expires April 1, 2003 [Page 17] =0C Internet-Draft SSH File Transfer Protocol October 2002 SSH_FXF_TEXT Indicates that the server should treat the file as text and convert it to the canonical newline convention in use. (See Determining Server Newline Convention. (Section 4.3) When a file is opened with the FXF_TEXT flag, the offset field in both the read and write function are ignored. Servers MUST correctly process multiple parallel reads and writes correctly in this mode. Naturally, it is permissible for them to do this by serializing the requests. It would not be possible for a client to reliably detect a server that does not implement parallel writes in time to prevent damage. Clients SHOULD use the SSH_FXF_APPEND flag to append data to a text file rather then using write with a calculated offset. To support seeks on text file the following SSH_FXP_EXTENDED packet is defined. string "text-seek" string file-handle uint64 line-number line-number is the index of the line number to seek to, where byte 0 in the file is line number 0, and the byte directly following the first newline sequence in the file is line number 1 and so on. The response to a "text-seek" request is an SSH_FXP_STATUS message. An attempt to seek past the end-of-file should result in a SSH_FX_EOF status. Servers SHOULD support at least one "text-seek" in order to support resume. However, a client MUST be prepared to receive SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. The client can then try a fall-back strategy, if it has one. Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned for read or write operations that are not sequential. The `attrs' field specifies the initial attributes for the file. Default values will be used for those attributes that are not specified. See Section ``File Attributes'' for more information. Galbraith, et al. Expires April 1, 2003 [Page 18] =0C Internet-Draft SSH File Transfer Protocol October 2002 The response to this message will be either SSH_FXP_HANDLE (if the operation is successful) or SSH_FXP_STATUS (if the operation fails). A file is closed by using the SSH_FXP_CLOSE request. Its data field has the following format: uint32 id string handle where `id' is the request identifier, and `handle' is a handle previously returned in the response to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The handle becomes invalid immediately after this request has been sent. The response to this request will be a SSH_FXP_STATUS message. One should note that on some server platforms even a close can fail. This can happen e.g. if the server operating system caches writes, and an error occurs while flushing cached writes during the close. 6.4 Reading and Writing Once a file has been opened, it can be read using the SSH_FXP_READ message, which has the following format: uint32 id string handle uint64 offset uint32 len where `id' is the request identifier, `handle' is an open file handle returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative to the beginning of the file from where to start reading, and `len' is the maximum number of bytes to read. In response to this request, the server will read as many bytes as it can from the file (up to `len'), and return them in a SSH_FXP_DATA message. If an error occurs or EOF is encountered before reading any data, the server will respond with SSH_FXP_STATUS. For normal disk files, it is guaranteed that this will read the specified number of bytes, or up to end of file. For e.g. device files this may return fewer bytes than requested. Writing to a file is achieved using the SSH_FXP_WRITE message, which has the following format: Galbraith, et al. Expires April 1, 2003 [Page 19] =0C Internet-Draft SSH File Transfer Protocol October 2002 uint32 id string handle uint64 offset string data where `id' is a request identifier, `handle' is a file handle returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the beginning of the file where to start writing, and `data' is the data to be written. The write will extend the file if writing beyond the end of the file. It is legal to write way beyond the end of the file; the semantics are to write zeroes from the end of the file to the specified offset and then the data. On most operating systems, such writes do not allocate disk space but instead leave "holes" in the file. The server responds to a write request with a SSH_FXP_STATUS message. 6.5 Removing and Renaming Files Files can be removed using the SSH_FXP_REMOVE message. It has the following format: uint32 id string filename [UTF-8] where `id' is the request identifier and `filename' is the name of the file to be removed. See Section ``File Names'' for more information. This request cannot be used to remove directories. The server will respond to this request with a SSH_FXP_STATUS message. Files (and directories) can be renamed using the SSH_FXP_RENAME message. Its data is as follows: uint32 id string oldpath [UTF-8] string newpath [UTF-8] where `id' is the request identifier, `oldpath' is the name of an existing file or directory, and `newpath' is the new name for the file or directory. It is an error if there already exists a file with the name specified by newpath. The server may also fail rename requests in other situations, for example if `oldpath' and `newpath' point to different file systems on the server. The server will respond to this request with a SSH_FXP_STATUS Galbraith, et al. Expires April 1, 2003 [Page 20] =0C Internet-Draft SSH File Transfer Protocol October 2002 message. 6.6 Creating and Deleting Directories New directories can be created using the SSH_FXP_MKDIR request. It has the following format: uint32 id string path [UTF-8] ATTRS attrs where `id' is the request identifier. `path' specifies the directory to be created. See Section ``File Names'' for more information on file names. `attrs' specifies the attributes that should be applied to it upon creation. Attributes are discussed in more detail in Section ``File Attributes''. The server will respond to this request with a SSH_FXP_STATUS message. If a file or directory with the specified path already exists, an error will be returned. Directories can be removed using the SSH_FXP_RMDIR request, which has the following format: uint32 id string path [UTF-8] where `id' is the request identifier, and `path' specifies the directory to be removed. See Section ``File Names'' for more information on file names. The server responds to this request with a SSH_FXP_STATUS message. Errors may be returned from this operation for various reasons, including, but not limited to, the path does not exist, the path does not refer to a directory object, the directory is not empty, or the user has insufficient access or permission to perform the requested operation. 6.7 Scanning Directories The files in a directory can be listed using the SSH_FXP_OPENDIR and SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or more file names with full file attributes for each file. The client should call SSH_FXP_READDIR repeatedly until it has found the file it is looking for or until the server responds with a Galbraith, et al. Expires April 1, 2003 [Page 21] =0C Internet-Draft SSH File Transfer Protocol October 2002 SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if there are no more files in the directory). The client should then close the handle using the SSH_FXP_CLOSE request. The SSH_FXP_OPENDIR opens a directory for reading. It has the following format: uint32 id string path [UTF-8] where `id' is the request identifier and `path' is the path name of the directory to be listed (without any trailing slash). See Section ``File Names'' for more information on file names. This will return an error if the path does not specify a directory or if the directory is not readable. The server will respond to this request with either a SSH_FXP_HANDLE or a SSH_FXP_STATUS message. Once the directory has been successfully opened, files (and directories) contained in it can be listed using SSH_FXP_READDIR requests. These are of the format uint32 id string handle where `id' is the request identifier, and `handle' is a handle returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to use an ordinary file handle returned by SSH_FXP_OPEN.) The server responds to this request with either a SSH_FXP_NAME or a SSH_FXP_STATUS message. One or more names may be returned at a time. Full status information is returned for each name in order to speed up typical directory listings. If there are no more names available to be read, the server MUST respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF. When the client no longer wishes to read more names from the directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be closed regardless of whether an error has occurred or not. 6.8 Retrieving File Attributes Very often, file attributes are automatically returned by SSH_FXP_READDIR. However, sometimes there is need to specifically retrieve the attributes for a named file. This can be done using the SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT Galbraith, et al. Expires April 1, 2003 [Page 22] =0C Internet-Draft SSH File Transfer Protocol October 2002 follows symbolic links on the server, whereas SSH_FXP_LSTAT does not follow symbolic links. Both have the same format: uint32 id string path [UTF-8] uint32 flags where `id' is the request identifier, and `path' specifies the file system object for which status is to be returned. The server responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. The flags field specify the attribute flags in which the client has particular interest. This is a hint to the server. For example, because retrieving owner / group and acl information can be an expensive operation under some operating systems, the server may choose not to retrieve this information unless the client expresses a specific interest in it. The client has no guarantee the server will provide all the fields that it has expressed an interest in. SSH_FXP_FSTAT differs from the others in that it returns status information for an open file (identified by the file handle). Its format is as follows: uint32 id string handle uint32 flags where `id' is the request identifier and `handle' is a file handle returned by SSH_FXP_OPEN. The server responds to this request with SSH_FXP_ATTRS or SSH_FXP_STATUS. 6.9 Setting File Attributes File attributes may be modified using the SSH_FXP_SETSTAT and SSH_FXP_FSETSTAT requests. These requests are used for operations such as changing the ownership, permissions or access times, as well as for truncating a file. The SSH_FXP_SETSTAT request is of the following format: uint32 id string path [UTF-8] ATTRS attrs where `id' is the request identifier, `path' specifies the file system object (e.g. file or directory) whose attributes are to be Galbraith, et al. Expires April 1, 2003 [Page 23] =0C Internet-Draft SSH File Transfer Protocol October 2002 modified, and `attrs' specifies the modifications to be made to its attributes. Attributes are discussed in more detail in Section ``File Attributes''. An error will be returned if the specified file system object does not exist or the user does not have sufficient rights to modify the specified attributes. The server responds to this request with a SSH_FXP_STATUS message. The SSH_FXP_FSETSTAT request modifies the attributes of a file which is already open. It has the following format: uint32 id string handle ATTRS attrs where `id' is the request identifier, `handle' (MUST be returned by SSH_FXP_OPEN) identifies the file whose attributes are to be modified, and `attrs' specifies the modifications to be made to its attributes. Attributes are discussed in more detail in Section ``File Attributes''. The server will respond to this request with SSH_FXP_STATUS. 6.10 Dealing with Symbolic links The SSH_FXP_READLINK request may be used to read the target of a symbolic link. It would have a data part as follows: uint32 id string path [UTF-8] where `id' is the request identifier and `path' specifies the path name of the symlink to be read. The server will respond with a SSH_FXP_NAME packet containing only one name and a dummy attributes value. The name in the returned packet contains the target of the link. If an error occurs, the server may respond with SSH_FXP_STATUS. The SSH_FXP_SYMLINK request will create a symbolic link on the server. It is of the following format uint32 id string linkpath [UTF-8] string targetpath [UTF-8] where `id' is the request identifier, `linkpath' specifies the path name of the symlink to be created and `targetpath' specifies the Galbraith, et al. Expires April 1, 2003 [Page 24] =0C Internet-Draft SSH File Transfer Protocol October 2002 target of the symlink. The server shall respond with a SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error condition. 6.11 Canonicalizing the Server-Side Path Name The SSH_FXP_REALPATH request can be used to have the server canonicalize any given path name to an absolute path. This is useful for converting path names containing ".." components or relative pathnames without a leading slash into absolute paths. The format of the request is as follows: uint32 id string path [UTF-8] where `id' is the request identifier and `path' specifies the path name to be canonicalized. The server will respond with a SSH_FXP_NAME packet containing the name in canonical form and a dummy attributes value. If an error occurs, the server may also respond with SSH_FXP_STATUS. 6.11.1 Best practice for dealing with paths The client SHOULD treat the results of SSH_FXP_REALPATH as a canonical absolute path, even if the path does not appear to be absolute. A client that use REALPATH(".") and treats the result as absolute, even if there is no leading slash, will continue to function correctly, even when talking to a Windows NT or VMS style system, where absolute paths may not begin with a slash. For example, if the client wishes to change directory up, and the server has returned "c:/x/y/z" from REALPATH, the client SHOULD use "c:/x/y/z/..". As a second example, if the client wishes to open the file "x.txt" in the current directory, and server has returned "dka100:/x/y/z" as the canonical path of the directory, the client SHOULD open "dka100:/x/y/ z/x.txt" Galbraith, et al. Expires April 1, 2003 [Page 25] =0C Internet-Draft SSH File Transfer Protocol October 2002 7. Responses from the Server to the Client The server responds to the client using one of a few response packets. All requests can return a SSH_FXP_STATUS response upon failure. When the operation is successful, any of the responses may be returned (depending on the operation). If no data needs to be returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME is used to return one or more file names from a SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests. Exactly one response will be returned for each request. Each response packet contains a request identifier which can be used to match each response with the corresponding request. Note that it is legal to have several requests outstanding simultaneously, and the server is allowed to send responses to them in a different order from the order in which the requests were sent (the result of their execution, however, is guaranteed to be as if they had been processed one at a time in the order in which the requests were sent). Response packets are of the same general format as request packets. Each response packet begins with the request identifier. The format of the data portion of the SSH_FXP_STATUS response is as follows: uint32 id uint32 error/status code string error message (ISO-10646 UTF-8 [RFC-2279]) string language tag (as defined in [RFC-1766]) where `id' is the request identifier, and `error/status code' indicates the result of the requested operation. The value SSH_FX_OK indicates success, and all other values indicate failure. Currently, the following values are defined (other values may be defined by future versions of this protocol): Galbraith, et al. Expires April 1, 2003 [Page 26] =0C Internet-Draft SSH File Transfer Protocol October 2002 #define SSH_FX_OK 0 #define SSH_FX_EOF 1 #define SSH_FX_NO_SUCH_FILE 2 #define SSH_FX_PERMISSION_DENIED 3 #define SSH_FX_FAILURE 4 #define SSH_FX_BAD_MESSAGE 5 #define SSH_FX_NO_CONNECTION 6 #define SSH_FX_CONNECTION_LOST 7 #define SSH_FX_OP_UNSUPPORTED 8 #define SSH_FX_INVALID_HANDLE 9 #define SSH_FX_NO_SUCH_PATH 10 #define SSH_FX_FILE_ALREADY_EXISTS 11 #define SSH_FX_WRITE_PROTECT 12 SSH_FX_OK Indicates successful completion of the operation. SSH_FX_EOF indicates end-of-file condition; for SSH_FX_READ it means that no more data is available in the file, and for SSH_FX_READDIR it indicates that no more files are contained in the directory. SSH_FX_NO_SUCH_FILE is returned when a reference is made to a file which does not exist. SSH_FX_PERMISSION_DENIED is returned when the authenticated user does not have sufficient permissions to perform the operation. SSH_FX_FAILURE is a generic catch-all error message; it should be returned if an error occurs for which there is no more specific error code defined. SSH_FX_BAD_MESSAGE may be returned if a badly formatted packet or protocol incompatibility is detected. SSH_FX_NO_CONNECTION is a pseudo-error which indicates that the client has no connection to the server (it can only be generated locally by the client, and MUST NOT be returned by servers). SSH_FX_CONNECTION_LOST is a pseudo-error which indicates that the connection to the server has been lost (it can only be generated locally by the client, and MUST NOT be returned by servers). Galbraith, et al. Expires April 1, 2003 [Page 27] =0C Internet-Draft SSH File Transfer Protocol October 2002 SSH_FX_OP_UNSUPPORTED indicates that an attempt was made to perform an operation which is not supported for the server (it may be generated locally by the client if e.g. the version number exchange indicates that a required feature is not supported by the server, or it may be returned by the server if the server does not implement an operation). SSH_FX_INVALID_HANDLE The handle value was invalid. SSH_FX_NO_SUCH_PATH The file path does not exist or is invalid. SSH_FX_FILE_ALREADY_EXISTS The file already exists. SSH_FX_WRITE_PROTECT The file is on read only media, or the media is write protected. The SSH_FXP_HANDLE response has the following format: uint32 id string handle where `id' is the request identifier, and `handle' is an arbitrary string that identifies an open file or directory on the server. The handle is opaque to the client; the client MUST NOT attempt to interpret or modify it in any way. The length of the handle string MUST NOT exceed 256 data bytes. The SSH_FXP_DATA response has the following format: uint32 id string data where `id' is the request identifier, and `data' is an arbitrary byte string containing the requested data. The data string may be at most the number of bytes requested in a SSH_FXP_READ request, but may also be shorter if end of file is reached or if the read is from something other than a regular file. The SSH_FXP_NAME response has the following format: Galbraith, et al. Expires April 1, 2003 [Page 28] =0C Internet-Draft SSH File Transfer Protocol October 2002 uint32 id uint32 count repeats count times: string filename [UTF-8] ATTRS attrs where `id' is the request identifier, `count' is the number of names returned in this response, and the remaining fields repeat `count' times (so that all three fields are first included for the first file, then for the second file, etc). In the repeated part, `filename' is a file name being returned (for SSH_FXP_READDIR, it will be a relative name within the directory, without any path components; for SSH_FXP_REALPATH it will be an absolute path name), and `attrs' is the attributes of the file as described in Section ``File Attributes''. The SSH_FXP_ATTRS response has the following format: uint32 id ATTRS attrs where `id' is the request identifier, and `attrs' is the returned file attributes as described in Section ``File Attributes''. Galbraith, et al. Expires April 1, 2003 [Page 29] =0C Internet-Draft SSH File Transfer Protocol October 2002 8. Vendor-Specific Extensions The SSH_FXP_EXTENDED request provides a generic extension mechanism for adding vendor-specific commands. The request has the following format: uint32 id string extended-request ... any request-specific data ... where `id' is the request identifier, and `extended-request' is a string of the format "name@domain", where domain is an internet domain name of the vendor defining the request. The rest of the request is completely vendor-specific, and servers should only attempt to interpret it if they recognize the `extended-request' name. The server may respond to such requests using any of the response packets defined in Section ``Responses from the Server to the Client''. Additionally, the server may also respond with a SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does not recognize the `extended-request' name, then the server MUST respond with SSH_FXP_STATUS with error/status set to SSH_FX_OP_UNSUPPORTED. The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary extension-specific data from the server to the client. It is of the following format: uint32 id ... any request-specific data ... There is a range of packet types reserved for use by extensions. In order to avoid collision, extensions that turn on the use of additional packet types should determine those numbers dynamically. The suggested way of doing this is have an extension request from the client to the server that enables the extension; the extension response from the server to the client would specify the actual type values to use, in additional to any other data. Extension authors should be mindful of the limited range of packet types available (there are only 45 values available) and avoid requiring a new packet type where possible. Galbraith, et al. Expires April 1, 2003 [Page 30] =0C Internet-Draft SSH File Transfer Protocol October 2002 9. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides file system access to arbitrary files on the server (only constrained by the server implementation). It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [8]. Care must be taken in the server implementation to check the validity of received file handle strings. The server should not rely on them directly; it MUST check the validity of each handle before relying on it. Galbraith, et al. Expires April 1, 2003 [Page 31] =0C Internet-Draft SSH File Transfer Protocol October 2002 10. Changes from previous protocol versions The SSH File Transfer Protocol has changed over time, before it's standardization. The following is a description of the incompatible changes between different versions. 10.1 Changes between versions 4 and 3 Many of the changes between version 4 and version 3 are to the attribute structure to make it more flexible for non-unix platforms. o Make all filenames UTF-8. o Added 'newline' extension. o Added 'case-sensitive' extension. o Made time fields 64 bit, and optionally have nanosecond resultion. o Made file attribute owner and group strings so they can actually be used on disparate systems. o Added createtime field, and added separate flags for atime, createtime, and mtime so they can be set separately. o Split the file type out of the permissions field and into it's own field (which is always present.) o Added acl attribute. o Added SSH_FXF_TEXT file open flag. o Added flags field to the get stat commands so that the client can specifically request information the server might not normally included for performance reasons. o Removed the long filename from the names structure-- it can now be built from information available in the attrs structure. o Added reserved range of packet numbers for extensions. o Added several additional error codes. 10.2 Changes between versions 3 and 2 o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. Galbraith, et al. Expires April 1, 2003 [Page 32] =0C Internet-Draft SSH File Transfer Protocol October 2002 o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were added. o The SSH_FXP_STATUS message was changed to include fields `error message' and `language tag'. 10.3 Changes between versions 2 and 1 o The SSH_FXP_RENAME message was added. 10.4 Changes between versions 1 and 0 o Implementation changes, no actual protocol changes. Galbraith, et al. Expires April 1, 2003 [Page 33] =0C Internet-Draft SSH File Transfer Protocol October 2002 11. Trademark Issues "ssh" is a registered trademark of SSH Communications Security Corp in the United States and/or other countries. Galbraith, et al. Expires April 1, 2003 [Page 34] =0C Internet-Draft SSH File Transfer Protocol October 2002 References [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000. [4] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", IEEE Standard 1003.2, 1996. [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- architecture-13 (work in progress), September 2002. [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh- transport-15 (work in progress), September 2002. [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 (work in progress), September 2002. [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh- userauth-16 (work in progress), September 2002. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Galbraith, et al. Expires April 1, 2003 [Page 35] =0C Internet-Draft SSH File Transfer Protocol October 2002 Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Galbraith, et al. Expires April 1, 2003 [Page 36] =0C Internet-Draft SSH File Transfer Protocol October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith, et al. Expires April 1, 2003 [Page 37] =0C ------=_NextPart_000_0013_01C29490.9901D1F0-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 04:24:39 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25395 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 04:24:38 -0500 (EST) Received: (qmail 12623 invoked by uid 605); 26 Nov 2002 09:27:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12616 invoked from network); 26 Nov 2002 09:27:16 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 26 Nov 2002 09:27:15 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18Gbzf-0005p3-00; Tue, 26 Nov 2002 09:26:59 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham <anakin@pobox.com> To: ietf-ssh@netbsd.org In-Reply-To: <001601c294cb$45904570$4d00a8c0@galb.vandyke.com> Subject: Re: New draft-draft of sftp... Message-Id: <E18Gbzf-0005p3-00@ixion.tartarus.org> Date: Tue, 26 Nov 2002 09:26:59 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joseph Galbraith <galb-list@vandyke.com> wrote: > o Added additional optional extension to allow the > server to tell the client that it compares files > in a case insensitive way, or that files are stored > in a case insensitive way. Since globbing is done > on the client, the client needs this information > to "get it right". In the absence of the extension, > client is to assume 'case sensitive'. Ooh, this is an interesting dilemma. The wildcard problems of SCP begin to percolate into SFTP... I'm not immediately disputing the usefulness of this SFTP extension, but I'm curious to know how other people think it should be handled in a client. Here's a pathological case to illustrate why it's non- trivial. I'm a client on a case-sensitive (say Unix) box, talking to a server on a machine such as Windows, which compares filenames case- insensitively but preserves the case they were created with. My user asks me to retrieve `A*'. If the user hasn't twigged that the server is case- insensitive, or perhaps hasn't twigged that a Unix SFTP client even cares, he may be implicitly assuming that a retrieve command with the wildcard `A*' will guaranteeably only write out local files matching the wildcard `A*', and hence that his existing files `averyimportantdocument', `apasswordfile' and `aroot- privilegedstartupscript' will be safe from this command. Even if that disaster doesn't occur, the user might still be surprised when he exits the SFTP client and then tries to copy `A*' into some other directory, and some of the new files don't get copied... What should I (the SFTP client) do? - Go ahead and retrieve all files which _case-insensitively_ match `A*', and write them out with local names, hence perhaps overwriting those three files? - Go ahead and retrieve all files which case-insensitively match `A*', and convert their names into a form which _case-sensitively_ matches the same wildcard? This would preserve the user's expectations of what local files would be unaffected, but could quite easily confuse him in all other respects. Particularly when straight upper- or lowercasing isn't sufficient, for example if he asked for A*b*C*d.TXT... - Ignore the server's plea of case-insensitivity, and only retrieve those server-side files which case-_sensitively_ match `A*'? - Figure out that there's a potential problem, and issue a warning and request for clarification? - Something even more complicated? Come to think of it, this problem already exists in current SFTP; a client on a Windows box being asked to _send_ `A*' to a Unix server has exactly the same set of choices, and if I'd ever got round to implementing wildcards in PSFTP then I would already have realised this :-) So what do existing clients do in this sort of situation? Is there a preferred policy? Cheers, Simon -- Simon Tatham What do we want? ROT13! <anakin@pobox.com> When do we want it? ABJ! From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 08:15:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29779 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 08:15:19 -0500 (EST) Received: (qmail 27513 invoked by uid 605); 26 Nov 2002 13:17:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27505 invoked from network); 26 Nov 2002 13:17:55 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 26 Nov 2002 13:17:55 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA12817; Tue, 26 Nov 2002 08:17:52 -0500 (EST) Date: Tue, 26 Nov 2002 8:17:51 EST From: Jeffrey Altman <jaltman@columbia.edu> Reply-To: jaltman@columbia.edu To: Simon Tatham <anakin@pobox.com> Cc: ietf-ssh@netbsd.org Subject: Re: New draft-draft of sftp... In-Reply-To: Your message of Tue, 26 Nov 2002 09:26:59 +0000 Message-ID: <CMM.0.91.0.1038316671.jaltman@watsun> Sender: ietf-ssh-owner@netbsd.org Precedence: list I recommend that people take a look at the archives for the last three months in the FTP-EXTS working group mailing list. This discussion is going to be a direct parallel to the discussions that took place there regarding the switch from server side pattern matching to client side pattern matching with the MLSD. Basically the end result is that for each file system on the host the client is going to need to know whether or not the file system is case-sensitive or not. Plus the client needs to know which characters are treated as special in the file system. And which are illegal. All of this is required for the client to have a chance to properly perform matching against server generated file names. In the FTP MLSD case, the FTP EXT group is arguing that the pattern matching rules that are to be applied are those of the client system and should only be applied after receiving from the host the complete list of file names. Therefore, host characteristics do not apply. Unfortunately, this argument fails on its face if you want to be able to script an operation that attempts to send a file to the host filename but the remote file system stores it as FILENAME so the check to see of the file arrived fails because the remote server is not performing the check. The Kermit project believes that globbing must be performed on the server. > Joseph Galbraith <galb-list@vandyke.com> wrote: > > o Added additional optional extension to allow the > > server to tell the client that it compares files > > in a case insensitive way, or that files are stored > > in a case insensitive way. Since globbing is done > > on the client, the client needs this information > > to "get it right". In the absence of the extension, > > client is to assume 'case sensitive'. > > Ooh, this is an interesting dilemma. The wildcard problems of SCP > begin to percolate into SFTP... > > I'm not immediately disputing the usefulness of this SFTP extension, > but I'm curious to know how other people think it should be handled > in a client. Here's a pathological case to illustrate why it's non- > trivial. > > I'm a client on a case-sensitive (say Unix) box, talking to a server > on a machine such as Windows, which compares filenames case- > insensitively but preserves the case they were created with. My user > asks me to retrieve `A*'. If the user hasn't twigged that the server > is case- insensitive, or perhaps hasn't twigged that a Unix SFTP > client even cares, he may be implicitly assuming that a retrieve > command with the wildcard `A*' will guaranteeably only write out > local files matching the wildcard `A*', and hence that his existing > files `averyimportantdocument', `apasswordfile' and `aroot- > privilegedstartupscript' will be safe from this command. Even if > that disaster doesn't occur, the user might still be surprised when > he exits the SFTP client and then tries to copy `A*' into some other > directory, and some of the new files don't get copied... What should > I (the SFTP client) do? > > - Go ahead and retrieve all files which _case-insensitively_ match > `A*', and write them out with local names, hence perhaps > overwriting those three files? > > - Go ahead and retrieve all files which case-insensitively match > `A*', and convert their names into a form which > _case-sensitively_ matches the same wildcard? This would preserve > the user's expectations of what local files would be unaffected, > but could quite easily confuse him in all other respects. > Particularly when straight upper- or lowercasing isn't > sufficient, for example if he asked for A*b*C*d.TXT... > > - Ignore the server's plea of case-insensitivity, and only retrieve > those server-side files which case-_sensitively_ match `A*'? > > - Figure out that there's a potential problem, and issue a warning > and request for clarification? > > - Something even more complicated? > > Come to think of it, this problem already exists in current SFTP; a > client on a Windows box being asked to _send_ `A*' to a Unix server > has exactly the same set of choices, and if I'd ever got round to > implementing wildcards in PSFTP then I would already have realised > this :-) So what do existing clients do in this sort of situation? > Is there a preferred policy? > > Cheers, > Simon > -- > Simon Tatham What do we want? ROT13! > <anakin@pobox.com> When do we want it? ABJ! > Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 11:20:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09036 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 11:20:24 -0500 (EST) Received: (qmail 11083 invoked by uid 605); 26 Nov 2002 16:23:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11076 invoked from network); 26 Nov 2002 16:23:03 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 26 Nov 2002 16:23:03 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05882; Tue, 26 Nov 2002 09:23:02 -0700 (MST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGN2XQ718532; Tue, 26 Nov 2002 08:23:02 -0800 (PST) Date: Tue, 26 Nov 2002 08:23:02 -0800 (PST) From: Darren J Moffat <Darren.Moffat@Sun.COM> To: Jeffrey Altman <jaltman@columbia.edu> cc: Simon Tatham <anakin@pobox.com>, <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... In-Reply-To: <CMM.0.91.0.1038316671.jaltman@watsun> Message-ID: <Pine.GSO.4.43.0211260818450.114147-100000@braveheart> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 26 Nov 2002, Jeffrey Altman wrote: > Basically the end result is that for each file system on the host the > client is going to need to know whether or not the file system is > case-sensitive or not. Plus the client needs to know which characters > are treated as special in the file system. And which are illegal. Which makes an assumption that there are sufficient APIs for userspace applications to enquire on this. I know of no such APIs on any system. But I could probably tell you off the top of my head the behaviour of a few different filesystems. Encoding this knowlege into an application is a bad idea. Writting a standard which encourages this thus a bad idea. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 11:28:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09535 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 11:28:49 -0500 (EST) Received: (qmail 15112 invoked by uid 605); 26 Nov 2002 16:31:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15104 invoked from network); 26 Nov 2002 16:31:28 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 26 Nov 2002 16:31:28 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA05656; Tue, 26 Nov 2002 11:31:14 -0500 (EST) Date: Tue, 26 Nov 2002 11:31:13 EST From: Jeffrey Altman <jaltman@columbia.edu> Reply-To: jaltman@columbia.edu To: Darren J Moffat <Darren.Moffat@Sun.COM> Cc: Simon Tatham <anakin@pobox.com>, <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... In-Reply-To: Your message of Tue, 26 Nov 2002 08:23:02 -0800 (PST) Message-ID: <CMM.0.91.0.1038328273.jaltman@watsun> Sender: ietf-ssh-owner@netbsd.org Precedence: list Darren Moffat wrote: > > On Tue, 26 Nov 2002, Jeffrey Altman wrote: > > > Basically the end result is that for each file system on the host the > > client is going to need to know whether or not the file system is > > case-sensitive or not. Plus the client needs to know which characters > > are treated as special in the file system. And which are illegal. > > Which makes an assumption that there are sufficient APIs for userspace > applications to enquire on this. I know of no such APIs on any system. > But I could probably tell you off the top of my head the behaviour of > a few different filesystems. Encoding this knowlege into an application > is a bad idea. Writting a standard which encourages this thus a bad idea. Exactly. Which goes directly to reason why globbing must be done on the system on which the file system is mounted. It is only on that system that the appropriate matches can be done by the file system. Trying to guess what the file system is capable or not capable of will only produce inaccurate results. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:03:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11003 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:03:58 -0500 (EST) Received: (qmail 7253 invoked by uid 605); 26 Nov 2002 17:06:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7245 invoked from network); 26 Nov 2002 17:06:37 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 26 Nov 2002 17:06:37 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18GjAP-0001cd-00; Tue, 26 Nov 2002 17:06:33 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham <anakin@pobox.com> In-Reply-To: <CMM.0.91.0.1038328273.jaltman@watsun> To: jaltman@columbia.edu Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... Message-Id: <E18GjAP-0001cd-00@ixion.tartarus.org> Date: Tue, 26 Nov 2002 17:06:33 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Jeffrey Altman <jaltman@columbia.edu> wrote: > Exactly. Which goes directly to reason why globbing must be done on > the system on which the file system is mounted. It is only on that > system that the appropriate matches can be done by the file system. > Trying to guess what the file system is capable or not capable of will > only produce inaccurate results. But this is only one side of the story. The other side is the user expectations, and the security angle. SCP is a good example of a protocol that does server-side globbing, and it's one most people on this list will have heard of :-) So suppose I'm an SCP user and I type a command such as scp myserver:[abc]*.* . to retrieve some files matching a wildcard, and copy them into my current directory. The server will now send back a list of file names and file contents, and my client program will create some files locally. What's to stop the server sending back a filename which _doesn't_ match the wildcard? Suppose it sends back `/etc/passwd'. Well, obviously my client can exercise minimal common sense and outlaw any inbound filename which contains a slash. But if it sends back some filename which _wasn't_ within the space of possible names I was expecting, then it can overwrite some local file I didn't want overwritten. And the client, knowing nothing about the globbing rules on the server, would have no way to check whether PASSWORDS.DAT really _did_ match the wildcard I'd specified. (The example above is carefully chosen; to a Unix user it seems obvious that PASSWORDS.DAT doesn't match it, but to a VMS user it seems just as obvious that it does!) Now suppose I'm talking to a Unix server, so I'm _expecting_ to get back files beginning with a or b; but suppose my server has been taken over by a malicious attacker. He can hack the SCP server process so that it sends back non-matching filenames, and there's nothing my client software can do to prevent it. So if I want to protect myself against this type of attack, then I must _always_ do a wildcard SCP download into an empty directory, so that there are no existing files that can be accidentally or maliciously overwritten by the server. I'm fairly sure this is not what most SCP users do! There are certainly undeniable reasons why client-side globbing causes problems. Unfortunately, I consider this to be an undeniable reason why server-side globbing can _also_ cause problems. Where does that leave us? On the one hand, we have potentially inaccurate results; on the other, we have a potential security hazard (although as far as I know I'm the only SCP implementor who considers it remotely important). Is there any middle way possible? Cheers, Simon -- Simon Tatham "_shin_, n. An ingenious device for <anakin@pobox.com> finding tables and chairs in the dark." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:10:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11263 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:09:59 -0500 (EST) Received: (qmail 10636 invoked by uid 605); 26 Nov 2002 17:12:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10629 invoked from network); 26 Nov 2002 17:12:40 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 26 Nov 2002 17:12:40 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA11576; Tue, 26 Nov 2002 12:12:31 -0500 (EST) Date: Tue, 26 Nov 2002 12:12:30 EST From: Jeffrey Altman <jaltman@columbia.edu> Reply-To: jaltman@columbia.edu To: Simon Tatham <anakin@pobox.com> Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... In-Reply-To: Your message of Tue, 26 Nov 2002 17:06:33 +0000 Message-ID: <CMM.0.91.0.1038330750.jaltman@watsun> Sender: ietf-ssh-owner@netbsd.org Precedence: list I am going to have to think about this concern for a bit. However, my initial reaction is that if the host has been hacked so that daemon services are replaced then I think you are in bigger trouble. At that point you can't count on the contents of any of the files you may receive from that server. Depending on what they are you will be hosed. > Jeffrey Altman <jaltman@columbia.edu> wrote: > > > Exactly. Which goes directly to reason why globbing must be done on > > the system on which the file system is mounted. It is only on that > > system that the appropriate matches can be done by the file system. > > Trying to guess what the file system is capable or not capable of will > > only produce inaccurate results. > > But this is only one side of the story. The other side is the user > expectations, and the security angle. > > SCP is a good example of a protocol that does server-side globbing, > and it's one most people on this list will have heard of :-) So > suppose I'm an SCP user and I type a command such as > > scp myserver:[abc]*.* . > > to retrieve some files matching a wildcard, and copy them into my > current directory. The server will now send back a list of file > names and file contents, and my client program will create some > files locally. > > What's to stop the server sending back a filename which _doesn't_ > match the wildcard? Suppose it sends back `/etc/passwd'. Well, > obviously my client can exercise minimal common sense and outlaw any > inbound filename which contains a slash. But if it sends back some > filename which _wasn't_ within the space of possible names I was > expecting, then it can overwrite some local file I didn't want > overwritten. And the client, knowing nothing about the globbing > rules on the server, would have no way to check whether > PASSWORDS.DAT really _did_ match the wildcard I'd specified. (The > example above is carefully chosen; to a Unix user it seems obvious > that PASSWORDS.DAT doesn't match it, but to a VMS user it seems just > as obvious that it does!) > > Now suppose I'm talking to a Unix server, so I'm _expecting_ to get > back files beginning with a or b; but suppose my server has been > taken over by a malicious attacker. He can hack the SCP server > process so that it sends back non-matching filenames, and there's > nothing my client software can do to prevent it. So if I want to > protect myself against this type of attack, then I must _always_ do > a wildcard SCP download into an empty directory, so that there are > no existing files that can be accidentally or maliciously > overwritten by the server. I'm fairly sure this is not what most SCP > users do! > > There are certainly undeniable reasons why client-side globbing > causes problems. Unfortunately, I consider this to be an undeniable > reason why server-side globbing can _also_ cause problems. Where > does that leave us? On the one hand, we have potentially inaccurate > results; on the other, we have a potential security hazard (although > as far as I know I'm the only SCP implementor who considers it > remotely important). Is there any middle way possible? > > Cheers, > Simon > -- > Simon Tatham "_shin_, n. An ingenious device for > <anakin@pobox.com> finding tables and chairs in the dark." > Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:15:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11515 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:15:48 -0500 (EST) Received: (qmail 15287 invoked by uid 605); 26 Nov 2002 17:18:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15200 invoked from network); 26 Nov 2002 17:18:02 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 26 Nov 2002 17:18:02 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18GjLQ-0002Dv-00; Tue, 26 Nov 2002 17:17:56 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham <anakin@pobox.com> In-Reply-To: <CMM.0.91.0.1038330750.jaltman@watsun> To: jaltman@columbia.edu Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... Message-Id: <E18GjLQ-0002Dv-00@ixion.tartarus.org> Date: Tue, 26 Nov 2002 17:17:56 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Jeffrey Altman <jaltman@columbia.edu> wrote: > I am going to have to think about this concern for a bit. However, my > initial reaction is that if the host has been hacked so that daemon > services are replaced then I think you are in bigger trouble. At that > point you can't count on the contents of any of the files you may > receive from that server. Depending on what they are you will be hosed. That's a fair point in many circumstances, of course; yes. Not every circumstance, though; suppose I was intending to download a bunch of archive files and then check their GPG signatures? In that situation I'm already protected against a malicious server changing the content of the files, so being unprotected against the same malicious server doing other damage to me is a step downward. Cheers, Simon -- Simon Tatham "A cynic is a person who smells flowers and <anakin@pobox.com> immediately looks around for a coffin." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:18:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11738 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:18:24 -0500 (EST) Received: (qmail 17576 invoked by uid 605); 26 Nov 2002 17:21:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17568 invoked from network); 26 Nov 2002 17:21:04 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 26 Nov 2002 17:21:04 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA12546; Tue, 26 Nov 2002 12:20:56 -0500 (EST) Date: Tue, 26 Nov 2002 12:20:56 EST From: Jeffrey Altman <jaltman@columbia.edu> Reply-To: jaltman@columbia.edu To: Simon Tatham <anakin@pobox.com> Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... In-Reply-To: Your message of Tue, 26 Nov 2002 17:17:56 +0000 Message-ID: <CMM.0.91.0.1038331256.jaltman@watsun> Sender: ietf-ssh-owner@netbsd.org Precedence: list > Jeffrey Altman <jaltman@columbia.edu> wrote: > > > I am going to have to think about this concern for a bit. However, my > > initial reaction is that if the host has been hacked so that daemon > > services are replaced then I think you are in bigger trouble. At that > > point you can't count on the contents of any of the files you may > > receive from that server. Depending on what they are you will be hosed. > > That's a fair point in many circumstances, of course; yes. > > Not every circumstance, though; suppose I was intending to download > a bunch of archive files and then check their GPG signatures? In > that situation I'm already protected against a malicious server > changing the content of the files, so being unprotected against the > same malicious server doing other damage to me is a step downward. > > Cheers, > Simon > -- > Simon Tatham "A cynic is a person who smells flowers and > <anakin@pobox.com> immediately looks around for a coffin." > That is assuming you have an out of band means of determining what the files names should be. If you don't have that then you are forced to rely on the trust of the server to provide you the correct file listings. Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:22:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11946 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:22:49 -0500 (EST) Received: (qmail 21285 invoked by uid 605); 26 Nov 2002 17:25:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21278 invoked from network); 26 Nov 2002 17:25:29 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 26 Nov 2002 17:25:29 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <W1LKV60T>; Tue, 26 Nov 2002 12:25:28 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA852@lespaul.process.com> From: Richard Whalen <Whalenr@process.com> To: ietf-ssh@netbsd.org Subject: RE: New draft-draft of sftp... Date: Tue, 26 Nov 2002 12:25:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list The SCP that I am familiary (F-Secure code) does client side "globbing", not server side. The command line given in the example would cause it to get a directory listing and apply the matching rules to the list of files received. -----Original Message----- From: Simon Tatham [mailto:anakin@pobox.com] Sent: Tuesday, November 26, 2002 12:07 PM To: jaltman@columbia.edu Cc: Darren J Moffat; ietf-ssh@netbsd.org Subject: Re: New draft-draft of sftp... Jeffrey Altman <jaltman@columbia.edu> wrote: > Exactly. Which goes directly to reason why globbing must be done on > the system on which the file system is mounted. It is only on that > system that the appropriate matches can be done by the file system. > Trying to guess what the file system is capable or not capable of will > only produce inaccurate results. But this is only one side of the story. The other side is the user expectations, and the security angle. SCP is a good example of a protocol that does server-side globbing, and it's one most people on this list will have heard of :-) So suppose I'm an SCP user and I type a command such as scp myserver:[abc]*.* . to retrieve some files matching a wildcard, and copy them into my current directory. The server will now send back a list of file names and file contents, and my client program will create some files locally. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:24:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12089 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:24:43 -0500 (EST) Received: (qmail 22345 invoked by uid 605); 26 Nov 2002 17:27:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22309 invoked from network); 26 Nov 2002 17:27:10 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 26 Nov 2002 17:27:10 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <W1LKV605>; Tue, 26 Nov 2002 12:27:09 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA853@lespaul.process.com> From: Richard Whalen <Whalenr@process.com> To: ietf-ssh@netbsd.org Subject: RE: New draft-draft of sftp... Date: Tue, 26 Nov 2002 12:27:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list "familiary" should be "familiar with" - I have no idea how that typo happened. -----Original Message----- From: Richard Whalen [mailto:whalenr@process.com] Sent: Tuesday, November 26, 2002 12:25 PM To: ietf-ssh@netbsd.org Subject: RE: New draft-draft of sftp... The SCP that I am familiary (F-Secure code) does client side "globbing", not server side. The command line given in the example would cause it to get a directory listing and apply the matching rules to the list of files received. -----Original Message----- From: Simon Tatham [mailto:anakin@pobox.com] Sent: Tuesday, November 26, 2002 12:07 PM To: jaltman@columbia.edu Cc: Darren J Moffat; ietf-ssh@netbsd.org Subject: Re: New draft-draft of sftp... Jeffrey Altman <jaltman@columbia.edu> wrote: > Exactly. Which goes directly to reason why globbing must be done on > the system on which the file system is mounted. It is only on that > system that the appropriate matches can be done by the file system. > Trying to guess what the file system is capable or not capable of will > only produce inaccurate results. But this is only one side of the story. The other side is the user expectations, and the security angle. SCP is a good example of a protocol that does server-side globbing, and it's one most people on this list will have heard of :-) So suppose I'm an SCP user and I type a command such as scp myserver:[abc]*.* . to retrieve some files matching a wildcard, and copy them into my current directory. The server will now send back a list of file names and file contents, and my client program will create some files locally. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 12:49:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13293 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 12:49:14 -0500 (EST) Received: (qmail 6788 invoked by uid 605); 26 Nov 2002 17:51:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6780 invoked from network); 26 Nov 2002 17:51:55 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.37.170) by mail.netbsd.org with SMTP; 26 Nov 2002 17:51:55 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id gAQHTJG03237 for ietf-ssh@netbsd.org; Tue, 26 Nov 2002 09:29:19 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: New draft-draft of sftp... Date: 26 Nov 2002 17:29:19 GMT Organization: University of California, Berkeley Lines: 27 Distribution: isaac Message-ID: <as0b1f$337$1@abraham.cs.berkeley.edu> References: <CMM.0.91.0.1038330750.jaltman@watsun> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1038331759 3175 128.32.153.211 (26 Nov 2002 17:29:19 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 26 Nov 2002 17:29:19 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Jeffrey Altman wrote: >I am going to have to think about this concern for a bit. However, my >initial reaction is that if the host has been hacked so that daemon >services are replaced then I think you are in bigger trouble. At that >point you can't count on the contents of any of the files you may >receive from that server. Depending on what they are you will be hosed. I don't agree. Suppose I run the following from my home directory: scp server:pretty*.jpg . Ok, so if the server is malicious, I can't count on the contents of those jpg files. Big deal -- the worst that happens is those pictures don't look so pretty to me, and I delete them. This sounds like a fairly manageable risk to me. But now suppose that the server is malicious and, unbeknownst to me, it returns a file that overwrites my ~/.forward file with the contents "|/bin/sh" Notice that now the server can send me email and cause arbitrary commands to be run under my account. The server thus gains complete control of my account, and possibly of my machine. This is a much more serious consequence, and one that I never would have expected. In other words, I don't agree that if the server is hacked you're in bigger trouble anyway. It looks to me like the globbing issue might make problems much more severe than they would have been in the absence of server-side globbing. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 14:42:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17676 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 14:42:43 -0500 (EST) Received: (qmail 19044 invoked by uid 605); 26 Nov 2002 19:45:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19037 invoked from network); 26 Nov 2002 19:45:18 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 26 Nov 2002 19:45:18 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18Gle1-0002Fm-00; Tue, 26 Nov 2002 19:45:17 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham <anakin@pobox.com> To: ietf-ssh@netbsd.org In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA852@lespaul.process.com> Subject: Re: New draft-draft of sftp... Message-Id: <E18Gle1-0002Fm-00@ixion.tartarus.org> Date: Tue, 26 Nov 2002 19:45:17 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Richard Whalen <Whalenr@process.com> wrote: > The SCP that I am familiary (F-Secure code) does client side "globbing", not > server side. > The command line given in the example would cause it to get a directory > listing and apply the matching rules to the list of files received. Sorry, yes, I should have been clearer; there are two entirely different things that go by the name SCP. One is the original `scp' program, which is basically the BSD rcp protocol using SSH instead of RSH as transport; the other is ssh.com's command-line batch-mode SFTP client with the same command syntax as the original scp program. I'm talking about the SCP _protocol_, which is to say the former. (PSCP supports both modes of operation, and it will give a security warning when it has to do a server-side glob, but if it's using SFTP then it will do client-side globbing without needing to warn about anything.) Cheers, Simon -- Simon Tatham "My heart bleeds. <anakin@pobox.com> (That's how it works.)" -- Gareth Taylor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 15:13:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18798 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 15:13:02 -0500 (EST) Received: (qmail 11258 invoked by uid 605); 26 Nov 2002 20:15:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11251 invoked from network); 26 Nov 2002 20:15:43 -0000 Received: from mx12.arcor-online.net (151.189.8.88) by mail.netbsd.org with SMTP; 26 Nov 2002 20:15:43 -0000 Received: from localhost (dsl-213-023-029-052.arcor-ip.net [213.23.29.52]) by mx12.arcor-online.net (Postfix) with ESMTP id 5947B3710; Tue, 26 Nov 2002 21:15:41 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 2B3AA34081; Tue, 26 Nov 2002 21:14:39 +0100 (CET) Date: Tue, 26 Nov 2002 21:14:38 +0100 From: Markus Friedl <markus@openbsd.org> To: David Wagner <daw@mozart.cs.berkeley.edu> Cc: ietf-ssh@netbsd.org Subject: Re: New draft-draft of sftp... Message-ID: <20021126201438.GA4565@folly> References: <CMM.0.91.0.1038330750.jaltman@watsun> <as0b1f$337$1@abraham.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <as0b1f$337$1@abraham.cs.berkeley.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Nov 26, 2002 at 05:29:19PM +0000, David Wagner wrote: > I don't agree. Suppose I run the following from my home directory: > scp server:pretty*.jpg . > Ok, so if the server is malicious, I can't count on the contents > of those jpg files. Big deal -- the worst that happens is those > pictures don't look so pretty to me, and I delete them. This sounds > like a fairly manageable risk to me. I agree with David: this is exactly why the sftp protocol is an improvment over rcp/scp. The client can retrieve complete directory listings and glob as it likes. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 26 17:38:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24106 for <secsh-archive@odin.ietf.org>; Tue, 26 Nov 2002 17:38:01 -0500 (EST) Received: (qmail 8133 invoked by uid 605); 26 Nov 2002 22:40:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8126 invoked from network); 26 Nov 2002 22:40:40 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 26 Nov 2002 22:40:40 -0000 Received: from [127.0.0.1] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1036890 for ietf-ssh@netbsd.org; Tue, 26 Nov 2002 15:40:39 -0700 Message-ID: <00df01c2959c$8b669d70$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" <galb-list@vandyke.com> To: <ietf-ssh@netbsd.org> References: <E18GjAP-0001cd-00@ixion.tartarus.org> Subject: Re: New draft-draft of sftp... Date: Tue, 26 Nov 2002 15:38:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > [snip] > > suppose I'm an SCP user and I type a command such as > > scp myserver:[abc]*.* . > > to retrieve some files matching a wildcard > > [snip] > > There are certainly undeniable reasons why client-side globbing > causes problems. Unfortunately, I consider this to be an undeniable > reason why server-side globbing can _also_ cause problems. Where > does that leave us? On the one hand, we have potentially inaccurate > results; on the other, we have a potential security hazard (although > as far as I know I'm the only SCP implementor who considers it > remotely important). Is there any middle way possible? Well, I liked my solution :-) Seriously, though, as your example pointed out, a VMS user and a unix user are expecting very different things in terms of how filenames are globbed. And as a user, I would be very surprised if globbing changed dramatically depending on what server I'm connecting to -- I personally think that what most users expect is that the globbing rules that they are used to (the ones of the client OS) will generaly be applied. Between this and the potential security issues being discussed about server side globbing, and the fact that sftp is written as a file sharing protocol (like NFS) as opposed to a file transfer protocol and I definitely believe that globbing belongs in the client, not the server. So really, to me, the question is what information does the client need to get this right. I haven't had the opportunity to review the FTP thread about this topic yet, but that is probably the next step. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 27 02:39:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02550 for <secsh-archive@odin.ietf.org>; Wed, 27 Nov 2002 02:39:41 -0500 (EST) Received: (qmail 21052 invoked by uid 605); 27 Nov 2002 07:42:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21045 invoked from network); 27 Nov 2002 07:42:17 -0000 Received: from elanus.its.uu.se (130.238.4.143) by mail.netbsd.org with SMTP; 27 Nov 2002 07:42:17 -0000 Received: from elanus (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 28CA04AFE; Wed, 27 Nov 2002 08:42:15 +0100 (NFT) Received: from elanus.its.uu.se(127.0.0.1) by elanus.its.uu.se via virus-scan id s21765; Wed, 27 Nov 02 08:42:13 +0100 Received: from r3.ekonomikum.uu.se (dns.ekonomikum.uu.se [130.238.166.240]) by elanus.its.uu.se (Postfix) with ESMTP id 416014AF3; Wed, 27 Nov 2002 08:42:13 +0100 (NFT) Received: (from pont@localhost) by r3.ekonomikum.uu.se (8.10.2+Sun/8.10.2) id gAR7gBF27169; Wed, 27 Nov 2002 08:42:11 +0100 (MET) X-Authentication-Warning: r3.ekonomikum.uu.se: pont set sender to pont@soua.net using -f From: Pontus Skoeld <pont_secsh@soua.net> To: "Joseph Galbraith" <galb-list@vandyke.com> Cc: <ietf-ssh@netbsd.org> Subject: Re: New draft-draft of sftp... References: <E18GjAP-0001cd-00@ixion.tartarus.org> <00df01c2959c$8b669d70$4d00a8c0@galb.vandyke.com> Date: 27 Nov 2002 08:42:11 +0100 In-Reply-To: <00df01c2959c$8b669d70$4d00a8c0@galb.vandyke.com> Message-ID: <ytyy97fbgrw.fsf@soua.net> Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02550 "Joseph Galbraith" <galb-list@vandyke.com> writes: > Seriously, though, as your example pointed out, a VMS user and a > unix user are expecting very different things in terms of how > filenames are globbed. This is an extremely important point. IMO globbing behaviour shall be consistent throughout the client, independent of what server it is connected to. A user that is used to file names being case-sensitive given the following file list alittlefile AnotherFile probably refers to alittlefile by a*, whereas someone used to case-insensitive name mean both files. This is a user property (and should probably be encoded in client behaviour), not a server property. Furthermore, I think this is really a non-problem. The server supplies a list of file names that can be used for globbing. There is no problem with doing case-sensitive (or case-insensitive) globbing with those names (the names returned by the server are valid, independent of how the user the user selects those file names). Neither are there any new problems introduced by the server above being able to refer to AnotherFile by the names anotherfile. A server that does case-sensitive matching might have both AnotherFile and anotherfile but not return anotherfile in the answers to readdir. To rephase this; to check for the existence of a file, use SSH_FXP_STAT, to avoid overwriting it, use SSH_FXF_EXCL. Using the answers from readdir for this is *wrong*. I have not yet had time to review the FTP thread, but I'll try to get around to that ASAP, but I'm not certain how much of that argumentation will be valid for sftp. /Pontus -- Pontus Sköld, see <URL:http://soua.net/> for more information. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 27 06:45:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06289 for <secsh-archive@odin.ietf.org>; Wed, 27 Nov 2002 06:45:12 -0500 (EST) Received: (qmail 19494 invoked by uid 605); 27 Nov 2002 11:47:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19487 invoked from network); 27 Nov 2002 11:47:50 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 27 Nov 2002 11:47:50 -0000 Received: from rockwelldatacorp.com (108.Red-80-33-216.pooles.rima-tde.net [80.33.216.108]) by narn.netbsd.org (Postfix) with SMTP id E4F3A11124 for <ietf-ssh@netbsd.org>; Wed, 27 Nov 2002 03:47:48 -0800 (PST) From: "J Schroeder" <j.schroeder@rockwelldatacorp.com> To: <ietf-ssh@netbsd.org> Subject: Urgent Unix Support Requirement for Frankfurt Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 27 Nov 2002 12:47:17 +0100 Reply-To: "J Schroeder" <j.schroeder@rockwelldatacorp.com> Message-Id: <20021127114749.E4F3A11124@narn.netbsd.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Hi. If any of you guys are looking (or know of anyone looking) for a new position in Frankfurt, I have a colleague looking for several Unix Support people there. Please drop me a mail if interested and I will forward details The rquirement involves: Knowledge of UNIX, SQL or programming languages, Standard Microsoft software, Native German speaker (also good knowledge of English) Best regards, J. Schroeder