From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 1 05:26:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02975 for ; Mon, 1 Sep 2003 05:26:49 -0400 (EDT) Received: (qmail 22235 invoked by uid 605); 1 Sep 2003 09:26:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22226 invoked from network); 1 Sep 2003 09:26:48 -0000 Received: from mail-in-05.arcor-online.net (151.189.21.45) by mail.netbsd.org with SMTP; 1 Sep 2003 09:26:48 -0000 Received: from localhost.arcor.net (dsl-213-023-020-206.arcor-ip.net [213.23.20.206]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 174237C653; Mon, 1 Sep 2003 11:26:47 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 840572D044; Mon, 1 Sep 2003 11:26:20 +0200 (CEST) Date: Mon, 1 Sep 2003 11:26:20 +0200 From: Markus Friedl To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030901092620.GA20557@folly> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 11:42:52PM -0400, Joel N. Weber II wrote: > I dislike the partial authentication approach. I believe it adds > significant complexity to an implementation. I agree, not only because of the implementation complexity. I don't see a reason why this sould be considered a 'partial authentication'. Why not treat this as two different methods and phase out the non-mic version instead of keeping the less secure version around forever? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 1 10:12:26 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07283 for ; Mon, 1 Sep 2003 10:12:26 -0400 (EDT) Received: (qmail 21637 invoked by uid 605); 1 Sep 2003 14:12:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21630 invoked from network); 1 Sep 2003 14:12:27 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 1 Sep 2003 14:12:27 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa25199; 1 Sep 2003 10:12 EDT Date: Mon, 1 Sep 2003 10:12:18 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: Nicolas Williams , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth 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 Fri, 29 Aug 2003, Jeffrey Hutzelman wrote: > Given that, I will work up some specific text describing this approach, > send it to the list, and prepare the next version of the draft for > submission over the weekend. Well, I'm almost there. Included below is the new text for section 4, describing the "gssapi-mic" authentication method. There are additional changes in sections 2 and 3 to refer to the new method and call out places where the eligible context changes, but I don't think there is any information not duplicated in the new section. Please send me and comments, implementation experience, etc. I still have a few other changes to make to the draft, but will likely submit a new version containing this text tomorrow. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA 4. GSSAPI MIC Authentication This section describes a user-authentication method which binds an existing GSSAPI context to the keys used for encryption and integrity protection of an SSH session. It is intended to be run over the SSH user authentication protocol [9], and used in conjunction with the key exchange methods described in Section 2 and with the user authentication methods described in Section 3. The authentication method name for this protocol is "gssapi-mic". This method makes use of an existing GSSAPI session established during a previous use of the "gssapi" user authentication method or of a key exchange method defined in accordance with Section 2. This method can improve the strength of user authentication when a GSSAPI mechainsm which provides integrity protection is used. It can also be used to allow user authentication to be performed using a GSSAPI context established during key exchange. At any given time, at most one GSSAPI context is available for use with this method. This is known as the "eligible context", and is selected as follows: o When the SSH session begins, there is no eligible context. o If the first key exchange is performed using a method defined in accordance with Section 2, and key exchange is successful, then the GSSAPI context established during key exchange becomes the eligible context. A context established during key exchanges performed for the purpose of rekeying can never become the eligible context. o Whenever a SSH_MSG_USERAUTH_GSSAPI_TOKEN message is sent or received during user authentication using the "gssapi" method, then the eligible context becomes unset (that is, after such a message there is no longer an eligible context). o If user authentication using the "gssapi" method results in a response of SSH_MSG_USERAUTH_FAILURE with the partial success flag set, and the context just established supports integrity protection (that is, the result of the final call to GSS_Init_sec_context() or GSS_Accept_sec_context() included the integ_avail flag), then that context just established becomes the eligible context. o If user authentication using this method ("gssapi-mic") results in a response of SSH_MSG_USERAUTH_FAILURE, then the eligible context becomes unset (that is, after such a message there is no longer an eligible context). o This method works only with context which supports integrity protection via GSS_GetMIC(), and no context which does not have this capability may become the eligible context. The server SHOULD include this user authentication method in the list of methods that can continue (in a SSH_MSG_USERAUTH_FAILURE) if there is an eligible context. It MUST NOT include this method if there is not an eligible context. The client SHOULD attempt to use this method if it is advertised by the server and there is an eligible context. The client MUST NOT attempt to use this method if there is no eligible context, even if it is advertised by the server. If a server receives a request for this method when there is no eligible context, it MUST return SSH_MSG_USERAUTH_FAILURE. This method is defined as a single message: byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-mic" string context id string MIC The context id field contains the string "keyex" if the eligible context resulted from key exchange, or the string "userauth" if the eligible context resulted from user authentication. This is done in order to insure that a MIC generated while using this method may be used only in the manner intended. The contents of the MIC field are obtained by calling GSS_GetMIC over the following, using the eligible context: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-mic" string context id Upon receiving this message when there is an eligible context, the server uses GSS_VerifyMIC() to verify that the MIC received is valid. If the MIC is not valid, the user authentication fails, and the server MUST return SSH_MSG_USERAUTH_FAILURE. If the MIC is valid and the server is satisfied as to the user's credentials, it MAY return either SSH_MSG_USERAUTH_SUCCESS, or SSH_MSG_USERAUTH_FAILURE with the partial success flag set, depending on whether additional authentications are needed. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 1 22:06:33 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20728 for ; Mon, 1 Sep 2003 22:06:33 -0400 (EDT) Received: (qmail 14707 invoked by uid 605); 2 Sep 2003 02:06:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14696 invoked from network); 2 Sep 2003 02:06:34 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 2 Sep 2003 02:06:34 -0000 Received: from mindrot.org (116.195.20.10.dhcp.netstarnetworks.com [10.20.195.116] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h8229SQ26143; Tue, 2 Sep 2003 12:09:28 +1000 Message-ID: <3F53FAF2.9@mindrot.org> Date: Tue, 02 Sep 2003 12:05:38 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Markus Friedl CC: "Joel N. Weber II" , Jeffrey Hutzelman , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> <20030901092620.GA20557@folly> In-Reply-To: <20030901092620.GA20557@folly> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl wrote: > On Tue, Aug 26, 2003 at 11:42:52PM -0400, Joel N. Weber II wrote: > >>I dislike the partial authentication approach. I believe it adds >>significant complexity to an implementation. > > I agree, not only because of the implementation complexity. > > I don't see a reason why this sould be considered a > 'partial authentication'. Why not treat this as two > different methods and phase out the non-mic version > instead of keeping the less secure version around forever? Agreed. Abusing partial authentication to fix up a shortcoming in an draft auth method is a kludge to fix a mistake, no other auth method does (or should) work that way. I agree with Markus' suggested solution too. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 1 23:50:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14938 for ; Mon, 1 Sep 2003 23:50:59 -0400 (EDT) Received: (qmail 10542 invoked by uid 605); 2 Sep 2003 03:51:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10533 invoked from network); 2 Sep 2003 03:51:01 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 2 Sep 2003 03:51:01 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa25626; 1 Sep 2003 23:50 EDT Date: Mon, 1 Sep 2003 23:50:16 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Markus Friedl cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth In-Reply-To: <20030901092620.GA20557@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 1 Sep 2003, Markus Friedl wrote: > On Tue, Aug 26, 2003 at 11:42:52PM -0400, Joel N. Weber II wrote: > > I dislike the partial authentication approach. I believe it adds > > significant complexity to an implementation. > > I agree, not only because of the implementation complexity. > > I don't see a reason why this sould be considered a > 'partial authentication'. Why not treat this as two > different methods and phase out the non-mic version > instead of keeping the less secure version around forever? Eliminating the non-mic version means eliminating any support for GSSAPI mechanisms which are unable to provide integrity protection for application messages (i.e. gss_GetMIC). I think we already decided much earlier in the development of this specification that we didn't want to do that; are you suggesting we revisit that decision? Also, inventing a new method doesn't eliminate the need for something like gssapi-mic to be used in conjunction with GSSAPI-based key exchange. Why solve the same problem twice? -- 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 Tue Sep 2 05:19:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02694 for ; Tue, 2 Sep 2003 05:19:09 -0400 (EDT) Received: (qmail 11617 invoked by uid 605); 2 Sep 2003 09:19:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11610 invoked from network); 2 Sep 2003 09:19:09 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 2 Sep 2003 09:19:09 -0000 Received: from localhost.arcor.net (dsl-082-082-052-041.arcor-ip.net [82.82.52.41]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id BA434A3632; Tue, 2 Sep 2003 11:19:02 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id C4CDE2D044; Tue, 2 Sep 2003 11:18:35 +0200 (CEST) Date: Tue, 2 Sep 2003 11:18:35 +0200 From: Markus Friedl To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030902091835.GA21919@folly> References: <20030901092620.GA20557@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Sep 01, 2003 at 11:50:16PM -0400, Jeffrey Hutzelman wrote: > On Mon, 1 Sep 2003, Markus Friedl wrote: > > > On Tue, Aug 26, 2003 at 11:42:52PM -0400, Joel N. Weber II wrote: > > > I dislike the partial authentication approach. I believe it adds > > > significant complexity to an implementation. > > > > I agree, not only because of the implementation complexity. > > > > I don't see a reason why this sould be considered a > > 'partial authentication'. Why not treat this as two > > different methods and phase out the non-mic version > > instead of keeping the less secure version around forever? > > Eliminating the non-mic version means eliminating any support for GSSAPI > mechanisms which are unable to provide integrity protection for > application messages (i.e. gss_GetMIC). why not negotiate the 'mic' capatibility within the user authentication method instead of requiring chained methods? e.g. have the server side insist on the mic message for GSSAPI mechanims supporting. > I think we already decided much > earlier in the development of this specification that we didn't want to do > that; are you suggesting we revisit that decision? i don't know the use of an authentication mechanism without integrity protection. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 06:58:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10080 for ; Tue, 2 Sep 2003 06:58:21 -0400 (EDT) Received: (qmail 5160 invoked by uid 605); 2 Sep 2003 10:58:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5153 invoked from network); 2 Sep 2003 10:58:20 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 2 Sep 2003 10:58:20 -0000 Received: by xanthine.gratuitous.org with local; Tue, 02 Sep 2003 06:58:02 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: Markus Friedl , "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org In-reply-to: (message from Jeffrey Hutzelman on Mon, 1 Sep 2003 23:50:16 -0400 (EDT)) Subject: Re: gss userauth References: Message-Id: Date: Tue, 02 Sep 2003 06:58:02 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Eliminating the non-mic version means eliminating any support for GSSAPI > mechanisms which are unable to provide integrity protection for > application messages (i.e. gss_GetMIC). I think we already decided much > earlier in the development of this specification that we didn't want to do > that; are you suggesting we revisit that decision? > > Also, inventing a new method doesn't eliminate the need for something like > gssapi-mic to be used in conjunction with GSSAPI-based key exchange. Why > solve the same problem twice? Jeff, I think I sent mail to this list last week suggesting that we could leave the gssapi mechanism exactly the way it is for the theoretical gssapi mechanisms that don't support integrity, and create a new mechanism called gssapi-mic which does both context establishment and a mic, and then create another mechanism called gssapi-keyex which does a mic over the context established during keyex. I think that would address all of your concerns except perhaps the one of ``solving the same problem twice'', but I think that's really a red herring; you can have a set of message definitions and then a list of which message types are used with which userauth methods. And while I had claimed last week to have implemented the partial userauth approach last week and found it to not have significant complexity, that was before I'd seen the mail you'd sent off the list yesterday saying that the partial authentication flag needs to be set by the server, and interpreted by the client; I simply had gssapi always returning failure without any partial success. I'm concerned about the complexity that would be required to add the partial success flag as you seem to be planning to specify it; the obvious ways of dealing with it that I can think of involve adding another member to the structure that defines an authentication method, which involves changes to the code that calls the authentication methods, as well as potentially requiring minor changes to each non-gssapi authentication method to deal with initialization. Your proposal also has a bunch of new rules about when you can try which authentication method. If you go with my proposal of having a gssapi-mic method that does both context establishment and a mic, and a gssapi-keyex method that does just a mic, I believe the only thing you have to worry about at all wrt choosing which method to run when to add gssapi to an existing implementation is that you need to make sure that gssapi-keyex is fairly early in the list. And I really don't see what you buy by requiring that complexity that you're advocating. I'd really like to see something that can easily be implemented without modifying the API that authentication methods use. We have two openssh maintainers opposed to the partial authentication approach. And I have a preference against the partial authentication method; I've been working on an implementation of the gssapi-mic authentication method, and I've also written a patch for gnupg support of significant size. How much code for an ssh implementation have the partial authentication advocates written? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 07:28:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12177 for ; Tue, 2 Sep 2003 07:28:33 -0400 (EDT) Received: (qmail 21966 invoked by uid 605); 2 Sep 2003 11:28:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21957 invoked from network); 2 Sep 2003 11:28:33 -0000 Received: from mail-in-02.arcor-online.net (151.189.21.42) by mail.netbsd.org with SMTP; 2 Sep 2003 11:28:33 -0000 Received: from localhost.arcor.net (dsl-082-082-052-041.arcor-ip.net [82.82.52.41]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 4B886930D4; Tue, 2 Sep 2003 13:29:36 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id BE06F2D044; Tue, 2 Sep 2003 13:28:00 +0200 (CEST) Date: Tue, 2 Sep 2003 13:28:00 +0200 From: Markus Friedl To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030902112800.GA31475@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 06:58:02AM -0400, Joel N. Weber II wrote: > We have two openssh maintainers opposed to the partial authentication > approach. And I have a preference against the partial authentication > method; I've been working on an implementation of the gssapi-mic > authentication method, and I've also written a patch for gnupg support > of significant size. > > How much code for an ssh implementation have the partial > authentication advocates written? Simon's code for the partial authentication version is not very large. However, I don't like the approach of having a 'chain' of userauth methods for 'gssapi-mic'. The same reasoning could be used for a challenge-response based authentication method: just add a method for sending a challenge together with 'partial success' and use the existing password method for response verification. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 11:41:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08784 for ; Tue, 2 Sep 2003 11:41:37 -0400 (EDT) Received: (qmail 7300 invoked by uid 605); 2 Sep 2003 15:41:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7293 invoked from network); 2 Sep 2003 15:41:35 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 2 Sep 2003 15:41:35 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa26662; 2 Sep 2003 11:41 EDT Date: Tue, 2 Sep 2003 11:41:23 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Markus Friedl cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth In-Reply-To: <20030902091835.GA21919@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 2 Sep 2003, Markus Friedl wrote: > why not negotiate the 'mic' capatibility within the user > authentication method instead of requiring chained methods? I had a proposal for doing that, but it was pointed out to me by a couple of people that relying on a server sending SSH_MSG_UNIMPLEMENTED when it gets a message it doesn't understand is not safe, since some implementations don't always do so (last I heard, OpenSSH gets this wrong between the end of initial key exchange and the start of user authentication; it's reasonable to assume that other implementations get it wrong at other times). > > I think we already decided much > > earlier in the development of this specification that we didn't want to do > > that; are you suggesting we revisit that decision? > > i don't know the use of an authentication mechanism without > integrity protection. So you don't implement password or keyboard-interactive any more? Ordinarily I'd agree with you, but it seems clear to me that in this context, it's appropriate to consider such methods. Suppose someone builds their site around an authentication system that involves a challenge-response exchange between the server and a smart card held by the user. If they build a GSSAPI mechanism for that system, isn't it reasonable that they be able to use it with ssh, even though it doesn't provide any sort of shared secret? -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 12:30:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12745 for ; Tue, 2 Sep 2003 12:30:41 -0400 (EDT) Received: (qmail 562 invoked by uid 605); 2 Sep 2003 16:30:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 553 invoked from network); 2 Sep 2003 16:30:42 -0000 Received: from mail-in-03.arcor-online.net (151.189.21.43) by mail.netbsd.org with SMTP; 2 Sep 2003 16:30:42 -0000 Received: from localhost.arcor.net (dsl-082-082-052-041.arcor-ip.net [82.82.52.41]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 792E1A9615; Tue, 2 Sep 2003 18:30:41 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 7E5DB2D044; Tue, 2 Sep 2003 18:30:14 +0200 (CEST) Date: Tue, 2 Sep 2003 18:30:14 +0200 From: Markus Friedl To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030902163014.GA9039@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 12:10:32PM -0400, Jeffrey Hutzelman wrote: > - Maintaining backward compatibility for the existing deployed base, > so that people can transition without a flag day. that's easy if you use a different name for the method. > - Maintaining support for GSSAPI mechanisms which are unable to support > GSS_GetMIC() > - Not making gratuitous changes to work that's already been done. i don't see why this is necessary. > - Getting this done in a timely manner. > > I know there are implementors who are planning on doing releases in the > near future which include GSSAPI userauth (you know who you are). I'd > like to see those releases include support for the more secure variant, in OpenSSH 3.7 cannot ship a 'more secure variant'. It was even considered replacing "gssapi" userauth with "kerberos-2@ssh.com". From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 12:39:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13207 for ; Tue, 2 Sep 2003 12:39:17 -0400 (EDT) Received: (qmail 5606 invoked by uid 605); 2 Sep 2003 16:39:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5598 invoked from network); 2 Sep 2003 16:39:19 -0000 Received: from www.isc.netbsd.org (HELO narn.netbsd.org) (204.152.185.215) by mail.netbsd.org with SMTP; 2 Sep 2003 16:39:19 -0000 Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by narn.netbsd.org (Postfix) with SMTP id 3B4671116B for ; Tue, 2 Sep 2003 16:10:58 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa26691; 2 Sep 2003 12:10 EDT Date: Tue, 2 Sep 2003 12:10:32 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" Cc: Markus Friedl , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth 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 Tue, 2 Sep 2003, Joel N. Weber II wrote: > I'm concerned about the complexity that would be required to add the > partial success flag as you seem to be planning to specify it; the I don't specify how the partial success flag works; the ssh-userauth document does. If you think it's too hard to implement, you should comment on that issue separately, since that document has already passed WG last call and gone to the IESG, and time to make changes is running out. > Your proposal also has a bunch of new rules about when you can try > which authentication method. No, I add one new rule: you can only try gssapi-mic when you have an appropriate context to use. It's not a very difficult rule to follow; if you don't have a context, you can't possibly construct the request message. > And I really don't see what you buy by requiring that complexity that > you're advocating. I don't see that I'm advocating significant complexity. For an implementation of the ssh protocol that already supports gssapi userauth, adding support for gssapi-mic should be pretty easy. > I'd really like to see something that can easily be implemented > without modifying the API that authentication methods use. I know of no standard API. I'm not working on an add-on to OpenSSH; I'm working on an extension to the SSHv2 protocol. It should not be difficult to add the method I am proposing to an SSHv2 implementation which correctly implements the current SSH protocol drafts and the existing GSSAPI mechanisms. I know of at least one implementor other than OpenSSH who is already doing so, and at least three other people have outlined ways to do so in OpenSSH, including returning partial success from an authentication method and updating the list of mechanisms listed by the server. > We have two openssh maintainers opposed to the partial authentication > approach. And I have a preference against the partial authentication > method; I've been working on an implementation of the gssapi-mic > authentication method, and I've also written a patch for gnupg support > of significant size. > > How much code for an ssh implementation have the partial > authentication advocates written? I'll pretend you didn't just suggest that somehow your having written some patches for openssh makes your opinion more valuable or worthwhile than mine. This is an IETF working group, Joel -- everyone's opinion counts. Just to be clear... I don't really care what final form this takes. What I do care about is - Maintaining backward compatibility for the existing deployed base, so that people can transition without a flag day. - Maintaining support for GSSAPI mechanisms which are unable to support GSS_GetMIC() - Not making gratuitous changes to work that's already been done. - Getting this done in a timely manner. I know there are implementors who are planning on doing releases in the near future which include GSSAPI userauth (you know who you are). I'd like to see those releases include support for the more secure variant, in whatever form we end up agreeing on. Some have already begun to implement what we discussed last week, which I described formally in my message yesterday morning. I'm willing to go with another approach, if you can convince me that it maintains the goals of backward compatibility and support for non-integrity-capable mechanisms, that there's a real reason why it's better (not just that using partial authentication offends your sense of aesthetics), and that it won't in fact be harder for implementors to get right. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 12:56:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14345 for ; Tue, 2 Sep 2003 12:56:21 -0400 (EDT) Received: (qmail 16553 invoked by uid 605); 2 Sep 2003 16:56:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16398 invoked from network); 2 Sep 2003 16:56:16 -0000 Received: from www.isc.netbsd.org (HELO narn.netbsd.org) (204.152.185.215) by mail.netbsd.org with SMTP; 2 Sep 2003 16:56:16 -0000 Received: from mariner.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by narn.netbsd.org (Postfix) with SMTP id 8EE6811179 for ; Tue, 2 Sep 2003 16:22:50 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa26698; 2 Sep 2003 12:22 EDT Date: Tue, 2 Sep 2003 12:22:03 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Markus Friedl Cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth In-Reply-To: <20030902155905.GA30345@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 2 Sep 2003, Markus Friedl wrote: > On Tue, Sep 02, 2003 at 11:41:23AM -0400, Jeffrey Hutzelman wrote: > > On Tue, 2 Sep 2003, Markus Friedl wrote: > > > > > why not negotiate the 'mic' capatibility within the user > > > authentication method instead of requiring chained methods? > > > > I had a proposal for doing that, but it was pointed out to me by a couple > > of people that relying on a server sending SSH_MSG_UNIMPLEMENTED when it > > why do you need this for negotiating? My approach was to have new clients just send a new message containing the MIC, in place of the empty "exchange complete" message that current clients send. An old server receiving this new message would send SSH_MSG_UNIMPLEMENTED, and the new client would reply with the old completion message. I don't see any way to introduce up-front negotiation into an existing mechanism that doesn't already have it, without breaking interoperability with the existing implementations. If you have a suggestion that will work, please let me know. > > gets a message it doesn't understand is not safe, since some > > implementations don't always do so (last I heard, OpenSSH gets this wrong > > between the end of initial key exchange and the start of user > > i don't see this bug. The specific problem I'm talking about was in relation to a new transport message which would be used to allow a client to request and a server to send additional host keys. In this way, a client could obtain and store information about all of a host's keys, instead of just the one used for key exchange. The original intent was to specify that this exchange could happen any time after the first SSH_MSG_NEWKEYS. Unfortunately, from what I've been led to believe, at least some versions of the openssh server will react badly to getting a message they're not expecting immediately after SSH_MSG_NEWKEYS. I'll freely admit to not having read the code or tested this myself, but this possibility was enough to warrant recommending that clients defer sending the new message until later in the session. I don't remember who told me this, but I'm pretty sure it's someone who reads this list. It is, of course, also possible that this is an old bug which has been fixed. > password authentication always allow 'replay' attacks. If the attacker can see the original password. There are certainly challenge-response password protocols which are not subject to replay attacks but also don't provide any means of insuring the integrity of additional messages. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 13:08:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15667 for ; Tue, 2 Sep 2003 13:08:35 -0400 (EDT) Received: (qmail 22873 invoked by uid 605); 2 Sep 2003 17:08:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22866 invoked from network); 2 Sep 2003 17:08:37 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 2 Sep 2003 17:08:37 -0000 Received: by xanthine.gratuitous.org with local; Tue, 02 Sep 2003 13:08:30 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: "Joel N. Weber II" , Markus Friedl , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu In-reply-to: (message from Jeffrey Hutzelman on Tue, 2 Sep 2003 12:10:32 -0400 (EDT)) Subject: Re: gss userauth References: Message-Id: Date: Tue, 02 Sep 2003 13:08:30 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeff, could you please comment on what you don't like about my proposal to have a gssapi-mic method that does all of the messages gssapi currently does, followed by sending a mic, and then having a gssapi-keyex method that does a mic using the keyex context? I've sent two messages suggesting this before, but it's not at all clear that you've acknowleged that I've even proposed this; your reaction to Markus got into a tangent about SSH_MSG_UNIMPLEMENTED, which you don't need to get right in order for my proposal to work; and it also gets rid of the need for partial userauth. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 13:52:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21230 for ; Tue, 2 Sep 2003 13:52:02 -0400 (EDT) Received: (qmail 18040 invoked by uid 605); 2 Sep 2003 17:52:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18033 invoked from network); 2 Sep 2003 17:52:03 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 2 Sep 2003 17:52:03 -0000 Received: from localhost.arcor.net (dsl-082-082-052-041.arcor-ip.net [82.82.52.41]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 802FD85ED8; Tue, 2 Sep 2003 19:52:02 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 88DB12D044; Tue, 2 Sep 2003 19:51:35 +0200 (CEST) Date: Tue, 2 Sep 2003 19:51:35 +0200 From: Markus Friedl To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030902175135.GA22768@folly> References: <20030902155905.GA30345@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 12:22:03PM -0400, Jeffrey Hutzelman wrote: > My approach was to have new clients just send a new message containing the > MIC, in place of the empty "exchange complete" message that current > clients send. An old server receiving this new message would send > SSH_MSG_UNIMPLEMENTED, and the new client would reply with the old > completion message. but this would be a 'hack' not an improved replacement for "gssapi" > I don't see any way to introduce up-front negotiation into an existing > mechanism that doesn't already have it, without breaking interoperability > with the existing implementations. If you have a suggestion that will > work, please let me know. why not use a new method name if there are many existing implementations? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:03:47 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22039 for ; Tue, 2 Sep 2003 14:03:46 -0400 (EDT) Received: (qmail 26757 invoked by uid 605); 2 Sep 2003 18:03:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26732 invoked from network); 2 Sep 2003 18:03:46 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 2 Sep 2003 18:03:46 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa06932; 2 Sep 2003 14:03 EDT Date: Tue, 02 Sep 2003 14:03:27 -0400 From: Jeffrey Hutzelman To: Markus Friedl cc: "Joel N. Weber II" , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <3963130000.1062525807@minbar.fac.cs.cmu.edu> In-Reply-To: <20030902163014.GA9039@folly> References: <20030902163014.GA9039@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, September 02, 2003 18:30:14 +0200 Markus Friedl wrote: > On Tue, Sep 02, 2003 at 12:10:32PM -0400, Jeffrey Hutzelman wrote: >> - Maintaining backward compatibility for the existing deployed base, >> so that people can transition without a flag day. > > that's easy if you use a different name for the method. True. I didn't think that was what you meant by "negotiating within the method". >> - Maintaining support for GSSAPI mechanisms which are unable to support >> GSS_GetMIC() >> - Not making gratuitous changes to work that's already been done. > > i don't see why this is necessary. Well, the key word is "gratuitous". If a change is necessary, of course we'll do it. But I don't like to do the same work multiple times, and I imagine the people implementing this feel the same way. If it looks like the spec is going to keep changing every day, then no one will bother implementing it. I guess part of the source of my concern over this is that several people have indicated they want to take care of this quickly; it's frustrating to think you have concensus, write up a specification, have people starting to implement it, and then discover that the concensus is not as strong as you thought. I know that's not your fault, but perhaps it helps explain where I'm coming from. >> - Getting this done in a timely manner. >> >> I know there are implementors who are planning on doing releases in the >> near future which include GSSAPI userauth (you know who you are). I'd >> like to see those releases include support for the more secure variant, >> in > > OpenSSH 3.7 cannot ship a 'more secure variant'. It was even > considered replacing "gssapi" userauth with "kerberos-2@ssh.com". Just so I understand... Regardless of what approach we choose to solving this problem, you're not planning on making any changes before 3.7 ships? -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:10:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22503 for ; Tue, 2 Sep 2003 14:10:09 -0400 (EDT) Received: (qmail 1591 invoked by uid 605); 2 Sep 2003 18:10:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1584 invoked from network); 2 Sep 2003 18:10:10 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 2 Sep 2003 18:10:10 -0000 Received: from localhost.arcor.net (dsl-082-082-052-041.arcor-ip.net [82.82.52.41]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 4AFE69E6F6; Tue, 2 Sep 2003 20:10:06 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 544642D044; Tue, 2 Sep 2003 20:09:39 +0200 (CEST) Date: Tue, 2 Sep 2003 20:09:39 +0200 From: Markus Friedl To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030902180938.GA27996@folly> References: <20030902163014.GA9039@folly> <3963130000.1062525807@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3963130000.1062525807@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 02:03:27PM -0400, Jeffrey Hutzelman wrote: > > > >that's easy if you use a different name for the method. > > True. I didn't think that was what you meant by "negotiating within the > method". no, but now you can negotiate within the new method whether the GSSAPI mechanisms supports GSS_GetMIC. > Just so I understand... Regardless of what approach we choose to solving > this problem, you're not planning on making any changes before 3.7 ships? yes, i'm sorry, but it's too late. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:15:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22820 for ; Tue, 2 Sep 2003 14:15:09 -0400 (EDT) Received: (qmail 3872 invoked by uid 605); 2 Sep 2003 18:15:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3865 invoked from network); 2 Sep 2003 18:15:10 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 2 Sep 2003 18:15:10 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa06941; 2 Sep 2003 14:14 EDT Date: Tue, 02 Sep 2003 14:14:31 -0400 From: Jeffrey Hutzelman To: "Joel N. Weber II" cc: Markus Friedl , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <3972940000.1062526471@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, September 02, 2003 13:08:30 -0400 "Joel N. Weber II" wrote: > Jeff, could you please comment on what you don't like about my > proposal to have a gssapi-mic method that does all of the messages > gssapi currently does, followed by sending a mic, and then having a > gssapi-keyex method that does a mic using the keyex context? I've > sent two messages suggesting this before, but it's not at all clear > that you've acknowleged that I've even proposed this; your reaction to Er, sorry. Yes, of course I've seen this proposal. I think Markus is proposing essentially the same thing, and I assume it's the leading alternative to the gssapi-mic we've already discussed and specified (can you please use some other name; having two proposals which use the same method name is confusing). I'm not convinced that what you describe is actually easier to implement correctly. It may be easier to do in the openssh server, because it doesn't require filling in whatever support for partial authentication is missing, but openssh is not the only implementation by any means. I'd like to hear from implementors other than you on this question. I'm also not convinced that it's better than what we already have. The only real improvement seems to be that it doesn't require using partial authentication, which Markus finds distasteful. I've yet to see any argument as to _why_ using partial authentication is distasteful. My argument at this point boils down to not wanting to create unnecessary extra work for implementors. If the other implementors who have been involved in this discussion don't think this is a problem, then I'll drop my objections. Note that it will still take me a couple of days to work up a revised version of the draft... > ... Markus got into a tangent about SSH_MSG_UNIMPLEMENTED, which you don't > need to get right in order for my proposal to work; and it also gets Yes; that was in relation to a much earlier proposal which I don't think I even mentioned on this list, except as a reaction to Markus's comments today. The gssapi-mic method doesn't require any particular behaviour with respect to unimplemented messages. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:20:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23297 for ; Tue, 2 Sep 2003 14:20:32 -0400 (EDT) Received: (qmail 6974 invoked by uid 605); 2 Sep 2003 18:20:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6965 invoked from network); 2 Sep 2003 18:20:32 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 2 Sep 2003 18:20:32 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa06950; 2 Sep 2003 14:20 EDT Date: Tue, 02 Sep 2003 14:20:21 -0400 From: Jeffrey Hutzelman To: Markus Friedl cc: "Joel N. Weber II" , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <3976020000.1062526821@minbar.fac.cs.cmu.edu> In-Reply-To: <20030902180938.GA27996@folly> References: <20030902163014.GA9039@folly> <3963130000.1062525807@minbar.fac.cs.cmu.edu> <20030902180938.GA27996@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, September 02, 2003 20:09:39 +0200 Markus Friedl wrote: > On Tue, Sep 02, 2003 at 02:03:27PM -0400, Jeffrey Hutzelman wrote: >> > >> > that's easy if you use a different name for the method. >> >> True. I didn't think that was what you meant by "negotiating within the >> method". > > no, but now you can negotiate within the new method whether > the GSSAPI mechanisms supports GSS_GetMIC. Actually, you can't. All you can do is try to establish a context, and look when you're done to see if integrity protection is supported. AFAIK there is no way in advance to tell whether a mechanism will support GSS_GetMIC or not. But this isn't actually a major problem. >> Just so I understand... Regardless of what approach we choose to >> solving this problem, you're not planning on making any changes before >> 3.7 ships? > > yes, i'm sorry, but it's too late. Ok; I just wanted to make sure I understood you correctly. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:25:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24182 for ; Tue, 2 Sep 2003 14:25:12 -0400 (EDT) Received: (qmail 9938 invoked by uid 605); 2 Sep 2003 18:25:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9931 invoked from network); 2 Sep 2003 18:25:13 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 2 Sep 2003 18:25:13 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa06954; 2 Sep 2003 14:24 EDT Date: Tue, 02 Sep 2003 14:24:40 -0400 From: Jeffrey Hutzelman To: Markus Friedl cc: "Joel N. Weber II" , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <3976930000.1062527080@minbar.fac.cs.cmu.edu> In-Reply-To: <20030902175135.GA22768@folly> References: <20030902155905.GA30345@folly> <20030902175135.GA22768@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, September 02, 2003 19:51:35 +0200 Markus Friedl wrote: > On Tue, Sep 02, 2003 at 12:22:03PM -0400, Jeffrey Hutzelman wrote: >> My approach was to have new clients just send a new message containing >> the MIC, in place of the empty "exchange complete" message that current >> clients send. An old server receiving this new message would send >> SSH_MSG_UNIMPLEMENTED, and the new client would reply with the old >> completion message. > > but this would be a 'hack' not an improved replacement for "gssapi" Well, a "replacement" would mean an incompatible mechanism, presumably with a new name. I was trying to avoid that, in part because I felt that extending an existing mechanism was preferable to inventing a new, almost-identical one, and I thought that implementors (including openssh) would feel the same way. In any case, I never actually made this proposal, so it's probably not worth picking it apart. I just wanted to give you an idea of what the alternative under discussion was when we decided to propose gssapi-mic. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:47:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25745 for ; Tue, 2 Sep 2003 14:47:54 -0400 (EDT) Received: (qmail 21280 invoked by uid 605); 2 Sep 2003 18:47:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21156 invoked from network); 2 Sep 2003 18:47:51 -0000 Received: from topper.inf.ed.ac.uk (129.215.32.40) by mail.netbsd.org with SMTP; 2 Sep 2003 18:47:51 -0000 Received: (from apache@localhost) by topper.inf.ed.ac.uk (8.11.6/8.11.6) id h82IlbU19023; Tue, 2 Sep 2003 19:47:37 +0100 From: Simon Wilkinson X-Authentication-Warning: topper.inf.ed.ac.uk: apache set sender to sxw@localhost using -f To: Jeffrey Hutzelman Subject: Re: gss userauth Message-ID: <1062528456.3f54e5c8ef742@mail.inf.ed.ac.uk> Date: Tue, 02 Sep 2003 19:47:36 +0100 (BST) Cc: "Joel N. Weber II" , Markus Friedl , =?ISO-8859-1?Q?Love_H=F6rnquis?==?ISO-8859-1?Q?t_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> In-Reply-To: <3972940000.1062526471@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Originating-IP: 213.94.214.130 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Quoting Jeffrey Hutzelman : > Er, sorry. Yes, of course I've seen this proposal. I think Markus is > proposing essentially the same thing, and I assume it's the leading > alternative to the gssapi-mic we've already discussed and specified (can > > you please use some other name; having two proposals which use the same > > method name is confusing). > > I'm not convinced that what you describe is actually easier to implement > correctly. Neither am I. There are several issues with having two different methods using the same messages, both in OpenSSH and, I would imagine in other protocols. If messages become overloaded, it becomes necessary for the application to keep track of the context in which those messages have occured (is this a gssapi, or a gssapi-mic message) for the entire exchange. It also doesn't give us a solution that we can simply extend to key exchange. There isn't any easy way for a client to decide whether a GSSAPI mechanism should be offered via the gssapi-mic or normal methods before it offers it. The client requires no particular knowledge of the underlying GSSAPI mechanism(s) its linked against, and I'd rather not add any. With mechanisms that require user interaction (secure tokens, for example), having the same mechansim tried twice (once with gssapi-mic, then again with gssapi when -mic fails), would be annoying to say the least. > It may be easier to do in the openssh server, because it > doesn't require filling in whatever support for partial authentication The 'missing' support for partial authentication requires about 3 lines of code to add to satisfy the needs of the proposed text. The gssapi-mic mechanism works equally well without partial authentication support. As Markus has said, the patch to add support for gssapi-mic is relatively straightforward. > My argument at this point boils down to not wanting to create > unnecessary extra work for implementors. Its important to realise just _how_ many implementations, and in turn, users, we already have out there. My GSSAPI patches have turned up in various forms in a large number of products. The strand supporting GSI are widely deployed across the Grid computing community as well. Personally, I feel that the gssapi-mic proposal is the best one for solving this problem in a general fashion that I've heard. Cheers, Simon. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 14:51:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26116 for ; Tue, 2 Sep 2003 14:51:37 -0400 (EDT) Received: (qmail 23195 invoked by uid 605); 2 Sep 2003 18:51:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23183 invoked from network); 2 Sep 2003 18:51:39 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 2 Sep 2003 18:51:39 -0000 Received: from localhost.arcor.net (dsl-082-082-052-041.arcor-ip.net [82.82.52.41]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 3FE278697D; Tue, 2 Sep 2003 20:51:38 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 4AA102D044; Tue, 2 Sep 2003 20:51:11 +0200 (CEST) Date: Tue, 2 Sep 2003 20:51:11 +0200 From: Markus Friedl To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030902185110.GA7202@folly> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3972940000.1062526471@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 02:14:31PM -0400, Jeffrey Hutzelman wrote: > I'm also not convinced that it's better than what we already have. The > only real improvement seems to be that it doesn't require using partial > authentication, which Markus finds distasteful. I've yet to see any > argument as to _why_ using partial authentication is distasteful. A server wants to enforce the use of a MIC, but has to offer "gssapi" instead of "gssapi-mic" as a method. Now all legacy clients can connect, they will choose "gssapi", progress until the method succeeds partially. But now they are stuck since the server only offers "gssapi-mic", so the complete "gssapi" is wasted. If you have distinct methods, then the server initially offers only "gssapi-mic". Then legacy clients can connect and choose a different method without problems. However, if the server offers "gssapi", they will always choose "gssapi", even if "gssapi" now means "gssapi"+"gssapi-mic". From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 15:32:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00133 for ; Tue, 2 Sep 2003 15:32:08 -0400 (EDT) Received: (qmail 14925 invoked by uid 605); 2 Sep 2003 19:32:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14918 invoked from network); 2 Sep 2003 19:32:10 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 2 Sep 2003 19:32:10 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h82JSZWN017125; Tue, 2 Sep 2003 13:28:35 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h82JSYcm006846; Tue, 2 Sep 2003 13:28:34 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h82JOxQx011904; Tue, 2 Sep 2003 12:24:59 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h82JOwYU011903; Tue, 2 Sep 2003 12:24:58 -0700 (PDT) Date: Tue, 2 Sep 2003 12:24:58 -0700 From: Nicolas Williams To: Damien Miller Cc: Markus Friedl , "Joel N. Weber II" , Jeffrey Hutzelman , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030902192455.GA11878@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> <20030901092620.GA20557@folly> <3F53FAF2.9@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F53FAF2.9@mindrot.org> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 12:05:38PM +1000, Damien Miller wrote: > Agreed. Abusing partial authentication to fix up a shortcoming in an > draft auth method is a kludge to fix a mistake, no other auth method > does (or should) work that way. I agree with Markus' suggested solution too. Partial userauth is useful for and needed to force the use of keyboard-interactive when you want users to change their passwords - that way users can't bypass password aging by using pubkey, hostbased or gss userauth. Partial userauth is fairly easy to implement for simple cases (such as password aging or the proposed update to gss and external-keyex userauth methods). Partial userauth is harder to implement for some of the cases proposed on the portable OpenSSH developer list, where userauth method vectors have been proposed. Here's a short description of how one might modify OpenSSH to support simple partial userauth, in case it might help you accept the proposed partial userauth fix to the gss draft issues: - add a boolean flag to the Authmethod structure to express userauth requirements (if set, the method MUST succeed before userauth succeeds) - initialize this flag to false for all methods (meaning that a single [enabled] method MUST succeed for userauth to succeed) - add a boolean function that indicates whether any enabled methods are marked as required - change authmethods_get() to return the list of required and enabled methods only, when there are any required and enabled methods - change userauth_finish() to reset the required flag of successful userauth methods - change userauth_finish() to determine that partial userauth failure occurs when a method succeeds but there remain required userauth methods Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 16:35:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05239 for ; Tue, 2 Sep 2003 16:35:35 -0400 (EDT) Received: (qmail 25031 invoked by uid 605); 2 Sep 2003 20:35:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25024 invoked from network); 2 Sep 2003 20:35:36 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 2 Sep 2003 20:35:36 -0000 Received: by xanthine.gratuitous.org with local; Tue, 02 Sep 2003 16:35:23 -0400 From: "Joel N. Weber II" To: Simon Wilkinson CC: Jeffrey Hutzelman , "Joel N. Weber II" , Markus Friedl , =?ISO-8859-1?Q?Love_H=F6rnquis?==?ISO-8859-1?Q?t_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu In-reply-to: <1062528456.3f54e5c8ef742@mail.inf.ed.ac.uk> (message from Simon Wilkinson on Tue, 02 Sep 2003 19:47:36 +0100 (BST)) Subject: Re: gss userauth References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <1062528456.3f54e5c8ef742@mail.inf.ed.ac.uk> Message-Id: Date: Tue, 02 Sep 2003 16:35:23 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > If messages become overloaded, it becomes necessary for the application to > keep track of the context in which those messages have occured (is this a > gssapi, or a gssapi-mic message) for the entire exchange. Doesn't this happen with privsep already, in a different sense? In the openssh implementation, this is probably what authctxt->methoddata is for... > The 'missing' support for partial authentication requires about 3 lines of > code to add to satisfy the needs of the proposed text. Looking at the code, I don't see how you can do that with 3 lines in a non-hackish fashion, but shrug. I haven't seen your patch, and I'm not sure that it's anywhere that I can see it. > The gssapi-mic > mechanism works equally well without partial authentication > support. It does work fine, as I've observed, but it also violates the spec Jeff is writing, unless what you're wrote is sufficiently ambiguous that we're thinking about two different things. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 17:10:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08010 for ; Tue, 2 Sep 2003 17:10:22 -0400 (EDT) Received: (qmail 15391 invoked by uid 605); 2 Sep 2003 21:10:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15378 invoked from network); 2 Sep 2003 21:10:22 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 2 Sep 2003 21:10:22 -0000 Received: from [172.29.84.18] (unknown [172.29.84.18]) by shitei.mindrot.org (Postfix) with ESMTP id 23D8427C189; Wed, 3 Sep 2003 07:07:32 +1000 (EST) Subject: Re: gss userauth From: Damien Miller To: Nicolas Williams Cc: Markus Friedl , "Joel N. Weber II" , Jeffrey Hutzelman , Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org In-Reply-To: <20030902192455.GA11878@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> <20030901092620.GA20557@folly> <3F53FAF2.9@mindrot.org> <20030902192455.GA11878@binky.central.sun.com> Content-Type: text/plain Message-Id: <1062536668.9292.61.camel@sakura.mindrot.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Sep 2003 07:04:29 +1000 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-09-03 at 05:24, Nicolas Williams wrote: > On Tue, Sep 02, 2003 at 12:05:38PM +1000, Damien Miller wrote: > > Agreed. Abusing partial authentication to fix up a shortcoming in an > > draft auth method is a kludge to fix a mistake, no other auth method > > does (or should) work that way. I agree with Markus' suggested solution too. > > Partial userauth is useful for and needed to force the use of > keyboard-interactive when you want users to change their passwords - > that way users can't bypass password aging by using pubkey, hostbased or > gss userauth. My criticism is not a partial userauth (which is useful), but its abuse to fix the shortcomings of GSSAPI auth. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 17:47:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10258 for ; Tue, 2 Sep 2003 17:47:48 -0400 (EDT) Received: (qmail 4742 invoked by uid 605); 2 Sep 2003 21:47:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4704 invoked from network); 2 Sep 2003 21:47:50 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 2 Sep 2003 21:47:50 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2150081; Tue, 02 Sep 2003 15:47:49 -0600 Message-ID: <3F551004.4070205@vandyke.com> Date: Tue, 02 Sep 2003 15:47:48 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: "Joel N. Weber II" , Markus Friedl , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> In-Reply-To: <3972940000.1062526471@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > On Tuesday, September 02, 2003 13:08:30 -0400 "Joel N. Weber II" > wrote: > >> Jeff, could you please comment on what you don't like about my >> proposal to have a gssapi-mic method that does all of the messages >> gssapi currently does, followed by sending a mic, and then having a >> gssapi-keyex method that does a mic using the keyex context? I've >> sent two messages suggesting this before, but it's not at all clear >> that you've acknowleged that I've even proposed this; your reaction to > > > Er, sorry. Yes, of course I've seen this proposal. I think Markus is > proposing essentially the same thing, and I assume it's the leading > alternative to the gssapi-mic we've already discussed and specified (can > you please use some other name; having two proposals which use the same > method name is confusing). Might I propose, for the time being, "gssapi-with-mic". > I'm not convinced that what you describe is actually easier to implement > correctly. It may be easier to do in the openssh server, because it > doesn't require filling in whatever support for partial authentication > is missing, but openssh is not the only implementation by any means. > I'd like to hear from implementors other than you on this question. > > I'm also not convinced that it's better than what we already have. The > only real improvement seems to be that it doesn't require using partial > authentication, which Markus finds distasteful. I've yet to see any > argument as to _why_ using partial authentication is distasteful. I originally was in support of the partial auth method... it seemed like a really elegant solution. However, after having taken a first pass at implementing it, I have to say the "gssapi-with-mic" has several advantages: o In order to implement compatability using "gssapi-mic" the server must use out-of-band information to determine whether the client can do "gssapi-mic". I.e., if the client can't do "gssapi-mic", the server can't send partial success on the "gssapi" and be backwards compatible. Using "gssapi-with-mic", the clients sending "gssapi-with-mic" implies it can do it. o Our software is highly modular C++. With "gssapi-mic", the object that implements "gssapi" and the object that implements gssapi key exchange must find someplace to put the token. Previously, we hadn't a much more limited form of this problem supporting "external-keyx". o "gssapi-mic" turned out to be much more complicated to specify than I had been thinking. In particular, specifying which context could be used was more complicated. Complex specifications are hard to implement correctly. If we were to go the "gssapi-with-mic" route, I would propose that we deprecate "gssapi" userauth, and do something like: "Integrity MUST be specified as an input to gss_init_sec_context(). If the resulting context supports integrity, the output of gss_getMic on must be included. Otherwise the "mic" string MUST be empty. It is a site policy descision for the server whether or not to accept for authentication gss mechanisms that do not support integrity. The server MAY fail the otherwise valid gssapi-with-mic authentication if integrity is not supported. Now we end up with only one authentication method, and it handles (securely, I believe) both the integrity and the non integrity cases. The problem with continuing to support both "gssapi" and "gssapi-with-mic" is that we are subject to downgrade attacks. Implementators that choose to support older clients will have this problem-- but, again, I believe that should be a site policy decision. And I think "gssapi-with-mic" may make it easier to implement this as a site policy. I'm also one of those looking for a solution quick -- I'm bumping up against an upcoming ship-date. So, I'm also in favor of a solution quickly-- so I'm willing to support "gssapi-mic" if it gets to a resolution quickly. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 18:20:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13472 for ; Tue, 2 Sep 2003 18:20:31 -0400 (EDT) Received: (qmail 23968 invoked by uid 605); 2 Sep 2003 22:20:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23961 invoked from network); 2 Sep 2003 22:20:33 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 2 Sep 2003 22:20:33 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h82MH9WN019047; Tue, 2 Sep 2003 16:17:09 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h82MH7cm021951; Tue, 2 Sep 2003 16:17:08 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h82MDWQx012182; Tue, 2 Sep 2003 15:13:32 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h82MDWOt012181; Tue, 2 Sep 2003 15:13:32 -0700 (PDT) Date: Tue, 2 Sep 2003 15:13:32 -0700 From: Nicolas Williams To: Markus Friedl Cc: Jeffrey Hutzelman , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030902221329.GA12152@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030902185110.GA7202@folly> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I find this convincing. On Tue, Sep 02, 2003 at 08:51:11PM +0200, Markus Friedl wrote: > On Tue, Sep 02, 2003 at 02:14:31PM -0400, Jeffrey Hutzelman wrote: > > I'm also not convinced that it's better than what we already have. The > > only real improvement seems to be that it doesn't require using partial > > authentication, which Markus finds distasteful. I've yet to see any > > argument as to _why_ using partial authentication is distasteful. > > A server wants to enforce the use of a MIC, but has to offer "gssapi" > instead of "gssapi-mic" as a method. > > Now all legacy clients can connect, they will choose "gssapi", > progress until the method succeeds partially. But now they are > stuck since the server only offers "gssapi-mic", so the complete > "gssapi" is wasted. > > If you have distinct methods, then the server initially offers only > "gssapi-mic". Then legacy clients can connect and choose a different > method without problems. > > However, if the server offers "gssapi", they will always choose > "gssapi", even if "gssapi" now means "gssapi"+"gssapi-mic". > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 19:36:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16949 for ; Tue, 2 Sep 2003 19:36:05 -0400 (EDT) Received: (qmail 5066 invoked by uid 605); 2 Sep 2003 23:36:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5059 invoked from network); 2 Sep 2003 23:36:05 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 2 Sep 2003 23:36:05 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa29334; 2 Sep 2003 19:36 EDT Date: Tue, 02 Sep 2003 19:35:49 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Markus Friedl cc: "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <4085560000.1062545749@minbar.fac.cs.cmu.edu> In-Reply-To: <20030902221329.GA12152@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, September 02, 2003 15:13:32 -0700 Nicolas Williams wrote: > I find this convincing. I think I do, too. However, I think if we do this, we need to effectively deprecate "gssapi" and make sure that we can use "gssapi-with-mic" even with contexts that can't support integrity, as Joseph described. Otherwise you run into the negotiation problem that Simon mentioned, where you might try the same mechanism twice. Now, the question is, who should advertise what? If a new server wants to insist on a MIC when possible, it should advertise only gssapi-with-mic, which makes the client's decision easy. If it wants to support authentication without a MIC, then you may as well always use gssapi, in which case the server could choose to advertise only that method (as older servers will). Unfortunately, that creates a problem. There is an unavoidable lack of interoperability between an older implementation which doesn't support gssapi-with-mic and a newer one which chooses (through site policy or implementor choice) not to support gssapi. But we don't want to break interoperability between new clients which choose not to support gssapi and new servers which happen to be operating in compatibility mode. So a server running in compatibility mode MUST also advertise gssapi-mic, so it will work with new clients. So now, when a new client talks to a new server with compatibility turned on, it sees the server advertise both methods. If a given GSS mechanism doesn't work with gssapi-with-mic, it's not going to work with gssapi either. So the client SHOULD NOT even try it, especially since, as Simon points out, there may be user interaction involved. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 20:46:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20152 for ; Tue, 2 Sep 2003 20:46:21 -0400 (EDT) Received: (qmail 12391 invoked by uid 605); 3 Sep 2003 00:46:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11975 invoked from network); 3 Sep 2003 00:46:05 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Sep 2003 00:46:05 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2151024; Tue, 02 Sep 2003 18:46:04 -0600 Message-ID: <3F5539CB.5050405@vandyke.com> Date: Tue, 02 Sep 2003 18:46:03 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Nicolas Williams , Markus Friedl , "Joel N. Weber II" , =?ISO-8859-1?Q?Love_H=F6?= =?ISO-8859-1?Q?rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> In-Reply-To: <4085560000.1062545749@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > I think I do, too. However, I think if we do this, we need to > effectively deprecate "gssapi" and make sure that we can use > "gssapi-with-mic" even with contexts that can't support integrity, as > Joseph described. Otherwise you run into the negotiation problem that > Simon mentioned, where you might try the same mechanism twice. > > Now, the question is, who should advertise what? > > If a new server wants to insist on a MIC when possible, it should > advertise only gssapi-with-mic, which makes the client's decision easy. > > If it wants to support authentication without a MIC, then you may as > well always use gssapi, in which case the server could choose to > advertise only that method (as older servers will). > > Unfortunately, that creates a problem. There is an unavoidable lack of > interoperability between an older implementation which doesn't support > gssapi-with-mic and a newer one which chooses (through site policy or > implementor choice) not to support gssapi. But we don't want to break > interoperability between new clients which choose not to support gssapi > and new servers which happen to be operating in compatibility mode. So > a server running in compatibility mode MUST also advertise gssapi-mic, > so it will work with new clients. Precisely. I believe a new server should alway advertise gssapi-with-mic. If it wishes to offer backwards compatibility, then it MAY advertise the older "gssapi". However, I'm not even sure we need to document "gssapi" in the new draft, other than to say it once existed, and SHOULD NOT be used anymore. I.e., reserve the name string as unused. New clients that choose to support both "gssapi" and "gssapi-with-mic" will need to be smart enough to prefer "gssapi-with-mic" The server, of course, should probably remove "gssapi" from the method list once "gssapi-with-mic" has been completed-- but I'm not even sure this is strictly necessary. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 21:16:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21626 for ; Tue, 2 Sep 2003 21:16:03 -0400 (EDT) Received: (qmail 25454 invoked by uid 605); 3 Sep 2003 01:16:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25447 invoked from network); 3 Sep 2003 01:16:05 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 3 Sep 2003 01:16:05 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h831Fq9D012132; Tue, 2 Sep 2003 18:15:52 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h831Fqcm009152; Tue, 2 Sep 2003 19:15:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h831CHQx012306; Tue, 2 Sep 2003 18:12:17 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h831CBWp012305; Tue, 2 Sep 2003 18:12:11 -0700 (PDT) Date: Tue, 2 Sep 2003 18:12:11 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Markus Friedl , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030903011211.GT11118@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4085560000.1062545749@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is there a list of GSS-API mechanisms that *don't* support integrity protection? Could you please post it? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 21:35:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22756 for ; Tue, 2 Sep 2003 21:35:49 -0400 (EDT) Received: (qmail 8030 invoked by uid 605); 3 Sep 2003 01:35:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8022 invoked from network); 3 Sep 2003 01:35:51 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 3 Sep 2003 01:35:51 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa26996; 2 Sep 2003 21:35 EDT Date: Tue, 2 Sep 2003 21:35:40 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: Markus Friedl , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth In-Reply-To: <20030903011211.GT11118@binky.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, 2 Sep 2003, Nicolas Williams wrote: > Is there a list of GSS-API mechanisms that *don't* support integrity > protection? Could you please post it? I don't believe there's even a list of GSSAPI mechanisms. Since they're named by OID's, there's no registration requirement. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 22:34:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25735 for ; Tue, 2 Sep 2003 22:34:11 -0400 (EDT) Received: (qmail 9109 invoked by uid 605); 3 Sep 2003 02:34:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9102 invoked from network); 3 Sep 2003 02:34:12 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 3 Sep 2003 02:34:12 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2003 19:34:12 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h832Y1s4000753; Tue, 2 Sep 2003 19:34:01 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.113.87]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Sep 2003 19:38:18 -0700 From: "Joseph Salowey" To: "'Joseph Galbraith'" , "'Jeffrey Hutzelman'" Cc: "'Nicolas Williams'" , "'Markus Friedl'" , "'Joel N. Weber II'" , "=?iso-8859-1?Q?'Love_H=F6rnquist_=C5strand'?=" , , Subject: RE: gss userauth Date: Tue, 2 Sep 2003 19:33:59 -0700 Message-ID: <011701c371c3$d5442440$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <3F5539CB.5050405@vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 03 Sep 2003 02:38:18.0878 (UTC) FILETIME=[6F25C1E0:01C371C4] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I agree with Joseph on this, I think 'gssapi' should be deprecated and its use discouraged except for a transitional period. Servers need to have the capability to remove 'gssapi' from the list when 'gssapi-with-mic' is implemented. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith > Sent: Tuesday, September 02, 2003 5:46 PM > To: Jeffrey Hutzelman > Cc: Nicolas Williams; Markus Friedl; Joel N. Weber II; Love=20 > H=F6rnquist =C5strand; ietf-ssh@NetBSD.org; jhutz+@cmu.edu > Subject: Re: gss userauth >=20 >=20 > > I think I do, too. However, I think if we do this, we need to > > effectively deprecate "gssapi" and make sure that we can use=20 > > "gssapi-with-mic" even with contexts that can't support=20 > integrity, as=20 > > Joseph described. Otherwise you run into the negotiation=20 > problem that=20 > > Simon mentioned, where you might try the same mechanism twice. > >=20 > > Now, the question is, who should advertise what? > >=20 > > If a new server wants to insist on a MIC when possible, it should > > advertise only gssapi-with-mic, which makes the client's=20 > decision easy. > >=20 > > If it wants to support authentication without a MIC, then you may as > > well always use gssapi, in which case the server could choose to=20 > > advertise only that method (as older servers will). > >=20 > > Unfortunately, that creates a problem. There is an=20 > unavoidable lack=20 > > of > > interoperability between an older implementation which=20 > doesn't support=20 > > gssapi-with-mic and a newer one which chooses (through site=20 > policy or=20 > > implementor choice) not to support gssapi. But we don't=20 > want to break=20 > > interoperability between new clients which choose not to=20 > support gssapi=20 > > and new servers which happen to be operating in=20 > compatibility mode. So=20 > > a server running in compatibility mode MUST also advertise=20 > gssapi-mic,=20 > > so it will work with new clients. >=20 > Precisely. I believe a new server should alway > advertise gssapi-with-mic. If it wishes to offer > backwards compatibility, then it MAY advertise > the older "gssapi". >=20 > However, I'm not even sure we need to document "gssapi" > in the new draft, other than to say it once existed, > and SHOULD NOT be used anymore. I.e., reserve the name > string as unused. >=20 > New clients that choose to support both "gssapi" and=20 > "gssapi-with-mic" will need to be smart enough to prefer=20 > "gssapi-with-mic" The server, of course, should probably=20 > remove "gssapi" from the method list once "gssapi-with-mic"=20 > has been completed-- but I'm not even sure this is strictly necessary. >=20 > - Joseph >=20 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 22:57:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27167 for ; Tue, 2 Sep 2003 22:57:08 -0400 (EDT) Received: (qmail 20252 invoked by uid 605); 3 Sep 2003 02:57:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20245 invoked from network); 3 Sep 2003 02:57:10 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 3 Sep 2003 02:57:10 -0000 Received: by xanthine.gratuitous.org with local; Tue, 02 Sep 2003 22:56:59 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Jeffrey Hutzelman , Markus Friedl , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu In-reply-to: <20030903011211.GT11118@binky.central.sun.com> (message from Nicolas Williams on Tue, 2 Sep 2003 18:12:11 -0700) Subject: Re: gss userauth References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <20030903011211.GT11118@binky.central.sun.com> Message-Id: Date: Tue, 02 Sep 2003 22:56:59 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Is there a list of GSS-API mechanisms that *don't* support integrity > protection? Could you please post it? I believe that the SRP GSSAPI mechanism that I've seen an internet-draft for but not an RFC doesn't do integrity protection, but it does do some kind of key generation. If you wanted to use that mechanism as it is currently specified, you'd probably actually want to either find some other GSSAPI mechanism that provides integrity protection to use with it, or specify the use of that key generation somehow. Or perhaps the mechanism could be modified to provide integrity somehow. But I'm not aware of anyone ever having any actual intent to use anything other than krb5 and gsi with ssh-gssapi. (Also, while SASL and GSSAPI are different, many of the obvious SASL mechanisms that don't do integrity are things for which there is already an ssh userauth mechanism that does some approximation of the same thing.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 2 23:02:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27531 for ; Tue, 2 Sep 2003 23:02:13 -0400 (EDT) Received: (qmail 22779 invoked by uid 605); 3 Sep 2003 03:02:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22772 invoked from network); 3 Sep 2003 03:02:15 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 3 Sep 2003 03:02:15 -0000 Received: by xanthine.gratuitous.org with local; Tue, 02 Sep 2003 23:02:10 -0400 From: "Joel N. Weber II" To: Joseph Galbraith CC: Jeffrey Hutzelman , "Joel N. Weber II" , Markus Friedl , =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu In-reply-to: <3F551004.4070205@vandyke.com> (message from Joseph Galbraith on Tue, 02 Sep 2003 15:47:48 -0600) Subject: Re: gss userauth References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <3F551004.4070205@vandyke.com> Message-Id: Date: Tue, 02 Sep 2003 23:02:10 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > "Integrity MUST be specified as an input to gss_init_sec_context(). > If the resulting context supports integrity, the output of > gss_getMic on must be included. Otherwise the > "mic" string MUST be empty. > > It is a site policy descision for the server whether or not > to accept for authentication gss mechanisms that do not > support integrity. The server MAY fail the otherwise valid > gssapi-with-mic authentication if integrity is not supported. I like the general idea behind this proposal. The only concern I have is that the language ought to specify that if you're supporting some mechanisms that do integrity and some that don't, you should not force the site policy to turn off the mic for the mechanisms that do support integrity. I'm not sure if gssapi gives you a better way to do this than allowing this to be configured on a per-mechanism basis. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 06:51:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22866 for ; Wed, 3 Sep 2003 06:51:39 -0400 (EDT) Received: (qmail 22472 invoked by uid 605); 3 Sep 2003 09:49:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22465 invoked from network); 3 Sep 2003 09:49:32 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 3 Sep 2003 09:49:32 -0000 Received: from localhost.arcor.net (dsl-213-023-020-109.arcor-ip.net [213.23.20.109]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id CD066A817D; Wed, 3 Sep 2003 11:49:30 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 8C9A32D044; Wed, 3 Sep 2003 11:49:04 +0200 (CEST) Date: Wed, 3 Sep 2003 11:49:04 +0200 From: Markus Friedl To: Joseph Galbraith Cc: Jeffrey Hutzelman , Nicolas Williams , "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030903094904.GD31840@folly> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <3F5539CB.5050405@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F5539CB.5050405@vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 06:46:03PM -0600, Joseph Galbraith wrote: > Precisely. I believe a new server should alway > advertise gssapi-with-mic. If it wishes to offer > backwards compatibility, then it MAY advertise > the older "gssapi". I agree, "gssapi" should only be offered for backward compatibility and legacy clients. During a transition period server can offer both "gssapi" and "gssapi-mic". > However, I'm not even sure we need to document "gssapi" > in the new draft, other than to say it once existed, > and SHOULD NOT be used anymore. I.e., reserve the name > string as unused. I agree. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 06:58:52 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23428 for ; Wed, 3 Sep 2003 06:58:51 -0400 (EDT) Received: (qmail 1535 invoked by uid 605); 3 Sep 2003 10:02:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1527 invoked from network); 3 Sep 2003 10:02:52 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 3 Sep 2003 10:02:52 -0000 Received: from localhost.arcor.net (dsl-213-023-020-109.arcor-ip.net [213.23.20.109]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 4E0E3A878E; Wed, 3 Sep 2003 12:02:51 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id DD11B2D044; Wed, 3 Sep 2003 12:02:24 +0200 (CEST) Date: Wed, 3 Sep 2003 12:02:24 +0200 From: Markus Friedl To: Simon Wilkinson Cc: Jeffrey Hutzelman , "Joel N. Weber II" , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030903100224.GG31840@folly> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <1062528456.3f54e5c8ef742@mail.inf.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1062528456.3f54e5c8ef742@mail.inf.ed.ac.uk> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 07:47:36PM +0100, Simon Wilkinson wrote: > If messages become overloaded, it becomes necessary for the application to > keep track of the context in which those messages have occured (is this a > gssapi, or a gssapi-mic message) for the entire exchange. I don't think this is the case, the state information of the client/server should keep track of the userauth method is in progress, so if (options.enforce_mic) becomes if (context->method == with_mic) -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 07:34:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25723 for ; Wed, 3 Sep 2003 07:34:58 -0400 (EDT) Received: (qmail 20599 invoked by uid 605); 3 Sep 2003 09:45:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20590 invoked from network); 3 Sep 2003 09:45:40 -0000 Received: from mail-in-05.arcor-online.net (151.189.21.45) by mail.netbsd.org with SMTP; 3 Sep 2003 09:45:40 -0000 Received: from localhost.arcor.net (dsl-213-023-020-109.arcor-ip.net [213.23.20.109]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 9917F80ACB; Wed, 3 Sep 2003 11:45:38 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 537D02D044; Wed, 3 Sep 2003 11:45:12 +0200 (CEST) Date: Wed, 3 Sep 2003 11:45:12 +0200 From: Markus Friedl To: Nicolas Williams Cc: Damien Miller , "Joel N. Weber II" , Jeffrey Hutzelman , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030903094512.GC31840@folly> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> <20030901092620.GA20557@folly> <3F53FAF2.9@mindrot.org> <20030902192455.GA11878@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030902192455.GA11878@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 12:24:58PM -0700, Nicolas Williams wrote: > Partial userauth is useful for and needed to force the use of > keyboard-interactive when you want users to change their passwords - > that way users can't bypass password aging by using pubkey, hostbased or > gss userauth. yes, partial userauth is useful, and i had it working similar to what you suggest, but it never went into an openssh release. the question is not whether partial user authentication is good or bad or easy to implement. to me, partial authentication is inapproriate in this gss/mic context. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 10:34:48 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09377 for ; Wed, 3 Sep 2003 10:34:47 -0400 (EDT) Received: (qmail 9207 invoked by uid 605); 3 Sep 2003 14:34:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9200 invoked from network); 3 Sep 2003 14:34:46 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 3 Sep 2003 14:34:46 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h83ET1qe003973; Wed, 3 Sep 2003 08:29:03 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h83ET1iB007735; Wed, 3 Sep 2003 08:29:01 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h83EPPQx012603; Wed, 3 Sep 2003 07:25:25 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h83EGDEk012594; Wed, 3 Sep 2003 07:16:13 -0700 (PDT) Date: Wed, 3 Sep 2003 07:16:13 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , Markus Friedl , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030903141009.GU11118@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <20030903011211.GT11118@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 02, 2003 at 10:56:59PM -0400, Joel N. Weber II wrote: > > Is there a list of GSS-API mechanisms that *don't* support integrity > > protection? Could you please post it? > > I believe that the SRP GSSAPI mechanism that I've seen an > internet-draft for but not an RFC doesn't do integrity protection, but > it does do some kind of key generation. If you wanted to use that > mechanism as it is currently specified, you'd probably actually want > to either find some other GSSAPI mechanism that provides integrity > protection to use with it, or specify the use of that key generation > somehow. Or perhaps the mechanism could be modified to provide > integrity somehow. My reading of draft-burdis-cat-srp-sasl-08 is that it does provide integrity protection. > But I'm not aware of anyone ever having any actual intent to use > anything other than krb5 and gsi with ssh-gssapi. Sun has a mechanism called DH (OIDs 1.3.6.4.1.42.2.26.2.4 and 1.3.6.4.1.42.2.26.2.5). Microsoft has NTLMSSP. > (Also, while SASL and GSSAPI are different, many of the obvious SASL > mechanisms that don't do integrity are things for which there is > already an ssh userauth mechanism that does some approximation of the > same thing.) Right. Same with EAP. Basically, anything which can't generate session keys with which to sign an SSHv2 session ID should be used with keyboard-interactive or should have its own userauth method. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 11:32:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15879 for ; Wed, 3 Sep 2003 11:32:39 -0400 (EDT) Received: (qmail 13351 invoked by uid 605); 3 Sep 2003 15:32:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13344 invoked from network); 3 Sep 2003 15:32:43 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 3 Sep 2003 15:32:43 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa18307; 3 Sep 2003 11:32 EDT Date: Wed, 03 Sep 2003 11:32:38 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , "Joel N. Weber II" cc: Markus Friedl , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <15722704.1062603158@minbar.fac.cs.cmu.edu> In-Reply-To: <20030903141009.GU11118@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <20030903011211.GT11118@binky.central.sun.com> <20030903141009.GU11118@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, September 03, 2003 07:16:13 -0700 Nicolas Williams wrote: > Right. Same with EAP. Basically, anything which can't generate session > keys with which to sign an SSHv2 session ID should be used with > keyboard-interactive or should have its own userauth method. No, I don't think that follows. There's no reason to invent a separate userauth method for a technology for which a GSSAPI mechanism already exists. The whole point of this exercise, and indeed of GSSAPI, is that you can use any GSS mechanism with any GSS-using application, without having to write n*m specifications and shepard them through the standards process. When someone invents a new GSSAPI mechanism, SSH automatically supports it. Application of this sort of modularity down at the network layer is one of the things that had made the Internet so successful - it was no longer necessary to specify how to run each application on top of each link layer. What would have happened if someone had said "any link later which can't provide reliable, ordered delivery of datagrams should have its own network layer, instead of using IP" ? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 14:15:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26916 for ; Wed, 3 Sep 2003 14:15:17 -0400 (EDT) Received: (qmail 14148 invoked by uid 605); 3 Sep 2003 18:15:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14105 invoked from network); 3 Sep 2003 18:15:16 -0000 Received: from hcl-mtl.gw.mcgill.ca (HELO fs1.montreal.hcl.com) (132.216.79.2) by mail.netbsd.org with SMTP; 3 Sep 2003 18:15:16 -0000 Received: from MTLGMATTHEWS ([198.168.185.62]) by fs1.montreal.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RWJBHZQS; Wed, 3 Sep 2003 14:15:14 -0400 Reply-To: From: "Glen Matthews" To: Subject: value for SSH_MSG_USERAUTH_GSSAPI_ERRTOK Date: Wed, 3 Sep 2003 14:24:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, i notice in draft-ietf-secsh-gsskeyex-06.txt that the value for SSH_MSG_USERAUTH_GSSAPI_ERRTOK is not defined. does anyone know what this should be (i guess *will* be in a future rev)? thanks glen From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 3 14:59:33 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29698 for ; Wed, 3 Sep 2003 14:59:33 -0400 (EDT) Received: (qmail 12441 invoked by uid 605); 3 Sep 2003 18:57:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12431 invoked from network); 3 Sep 2003 18:57:39 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 3 Sep 2003 18:57:39 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa19220; 3 Sep 2003 14:57 EDT Date: Wed, 03 Sep 2003 14:57:15 -0400 From: Jeffrey Hutzelman To: glen@montreal.hcl.com, ietf-ssh@NetBSD.org Subject: Re: value for SSH_MSG_USERAUTH_GSSAPI_ERRTOK Message-ID: <60762704.1062615435@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, September 03, 2003 14:24:03 -0400 Glen Matthews wrote: > Hi, > > i notice in draft-ietf-secsh-gsskeyex-06.txt that the value for > SSH_MSG_USERAUTH_GSSAPI_ERRTOK is not defined. does anyone know what this > should be (i guess *will* be in a future rev)? thanks I thought I already answered this question. The correct value is 65, and will appear in the next version of the document. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 4 15:19:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17002 for ; Thu, 4 Sep 2003 15:19:40 -0400 (EDT) Received: (qmail 23833 invoked by uid 605); 4 Sep 2003 19:19:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23826 invoked from network); 4 Sep 2003 19:19:37 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 4 Sep 2003 19:19:37 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h84JJbt6014582; Thu, 4 Sep 2003 13:19:37 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h84JJatK023233; Thu, 4 Sep 2003 15:19:36 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h84JJZue020161; Thu, 4 Sep 2003 15:19:35 -0400 (EDT) Message-Id: <200309041919.h84JJZue020161@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org cc: smb@research.att.com, Russ Housley Subject: Steve Bellovin: secsh security considerations Reply-to: sommerfeld@east.sun.com Date: Thu, 04 Sep 2003 15:19:35 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I just got a batch of comments from the IESG which I will be sorting through and passing on to the WG. But I couldn't wait on forwarding this. Thanks to all who contributed to the security considerations, and in particular to Chris Lonvick for pulling the text together.. - Bill ------- Forwarded Message From: Steve Bellovin To: sommerfeld@east.sun.com Subject: secsh security considerations Cc: housley@vigilsec.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 2003 14:54:37 -0400 Message-Id: <20030904185437.893CC7B43@berkshire.research.att.com> Content-Length: 176 Bill, please pass on my compliments to the authors of the new security considerations section -- it's truly excellent --Steve Bellovin, http://www.research.att.com/~smb ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 4 18:29:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28074 for ; Thu, 4 Sep 2003 18:29:50 -0400 (EDT) Received: (qmail 13888 invoked by uid 605); 4 Sep 2003 22:29:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13876 invoked from network); 4 Sep 2003 22:29:48 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Sep 2003 22:29:48 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2165034; Thu, 04 Sep 2003 16:29:47 -0600 Message-ID: <3F57BCDB.3050503@vandyke.com> Date: Thu, 04 Sep 2003 16:29:47 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Nicolas Williams , Markus Friedl , "Joel N. Weber II" , =?ISO-8859-1?Q?Love_H=F6?= =?ISO-8859-1?Q?rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> In-Reply-To: <4085560000.1062545749@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit All right-- so the big question is-- have we reached consensus for reals this time? Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 4 20:01:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03547 for ; Thu, 4 Sep 2003 20:01:55 -0400 (EDT) Received: (qmail 24968 invoked by uid 605); 5 Sep 2003 00:01:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24956 invoked from network); 5 Sep 2003 00:01:54 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 5 Sep 2003 00:01:54 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h8501ot6027422; Thu, 4 Sep 2003 18:01:50 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8501niB024259; Thu, 4 Sep 2003 18:01:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h84NwDQx013734; Thu, 4 Sep 2003 16:58:13 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h84Nw93C013733; Thu, 4 Sep 2003 16:58:09 -0700 (PDT) Date: Thu, 4 Sep 2003 16:58:09 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: Jeffrey Hutzelman , Markus Friedl , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030904235809.GY11118@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <3F57BCDB.3050503@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F57BCDB.3050503@vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Sep 04, 2003 at 04:29:47PM -0600, Joseph Galbraith wrote: > All right-- so the big question is-- > have we reached consensus for reals > this time? What's the consensus? That gssapi and external-keyex userauth are to be deprecated and replaced with forms that correctly bind the context to the session? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 4 20:22:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04504 for ; Thu, 4 Sep 2003 20:22:17 -0400 (EDT) Received: (qmail 4964 invoked by uid 605); 5 Sep 2003 00:22:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4957 invoked from network); 5 Sep 2003 00:22:19 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 5 Sep 2003 00:22:19 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa29360; 4 Sep 2003 20:22 EDT Date: Thu, 04 Sep 2003 20:22:07 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Joseph Galbraith cc: Markus Friedl , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <404572704.1062721327@minbar.fac.cs.cmu.edu> In-Reply-To: <20030904235809.GY11118@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <3F57BCDB.3050503@vandyke.com> <20030904235809.GY11118@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, September 04, 2003 16:58:09 -0700 Nicolas Williams wrote: > On Thu, Sep 04, 2003 at 04:29:47PM -0600, Joseph Galbraith wrote: >> All right-- so the big question is-- >> have we reached consensus for reals >> this time? > > What's the consensus? That gssapi and external-keyex userauth are to be > deprecated and replaced with forms that correctly bind the context to > the session? Yes. Particularly: - Obsolete external-keyex; it should not be used. - Replace 'gssapi' with 'gssapi-with-mic' - Add 'gssapi-keyex' to send a MIC using the context established during key exchange. I will send some text for the latter two sometime tomorrow morning. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 4 20:26:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04699 for ; Thu, 4 Sep 2003 20:26:22 -0400 (EDT) Received: (qmail 6857 invoked by uid 605); 5 Sep 2003 00:26:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6850 invoked from network); 5 Sep 2003 00:26:24 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 5 Sep 2003 00:26:24 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h850QLhi024378; Thu, 4 Sep 2003 18:26:21 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h850QLZF001136; Thu, 4 Sep 2003 18:26:21 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h850MiQx013758; Thu, 4 Sep 2003 17:22:44 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h850MiR0013757; Thu, 4 Sep 2003 17:22:44 -0700 (PDT) Date: Thu, 4 Sep 2003 17:22:44 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Joseph Galbraith , Markus Friedl , "Joel N. Weber II" , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org, jhutz+@cmu.edu Subject: Re: gss userauth Message-ID: <20030905002243.GZ11118@binky.central.sun.com> References: <3972940000.1062526471@minbar.fac.cs.cmu.edu> <20030902185110.GA7202@folly> <20030902221329.GA12152@binky.central.sun.com> <4085560000.1062545749@minbar.fac.cs.cmu.edu> <3F57BCDB.3050503@vandyke.com> <20030904235809.GY11118@binky.central.sun.com> <404572704.1062721327@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404572704.1062721327@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Sep 04, 2003 at 08:22:07PM -0400, Jeffrey Hutzelman wrote: > On Thursday, September 04, 2003 16:58:09 -0700 Nicolas Williams > wrote: > >On Thu, Sep 04, 2003 at 04:29:47PM -0600, Joseph Galbraith wrote: > >>All right-- so the big question is-- > >>have we reached consensus for reals > >>this time? > > > >What's the consensus? That gssapi and external-keyex userauth are to be > >deprecated and replaced with forms that correctly bind the context to > >the session? > > Yes. Particularly: > > - Obsolete external-keyex; it should not be used. > - Replace 'gssapi' with 'gssapi-with-mic' > - Add 'gssapi-keyex' to send a MIC using the context established during key > exchange. So, obsolete and replace the two gss-related userauths. I agree. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 10:40:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27145 for ; Fri, 5 Sep 2003 10:40:00 -0400 (EDT) Received: (qmail 4332 invoked by uid 605); 5 Sep 2003 14:40:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4325 invoked from network); 5 Sep 2003 14:40:02 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 5 Sep 2003 14:40:02 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27118; Fri, 5 Sep 2003 10:39:55 -0400 (EDT) Message-Id: <200309051439.KAA27118@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-05.txt Date: Fri, 05 Sep 2003 10:39:55 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Using DNS to Securely Publish SSH Key Fingerprints Author(s) : J. Schlyter, W. Griffin Filename : draft-ietf-secsh-dns-05.txt Pages : 11 Date : 2003-9-5 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-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-dns-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-dns-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: <2003-9-5084714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dns-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dns-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-5084714.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 12:13:11 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03197 for ; Fri, 5 Sep 2003 12:13:10 -0400 (EDT) Received: (qmail 29234 invoked by uid 605); 5 Sep 2003 16:13:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29161 invoked from network); 5 Sep 2003 16:13:08 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 5 Sep 2003 16:13:08 -0000 Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa30532; 5 Sep 2003 12:12 EDT Date: Fri, 05 Sep 2003 12:12:53 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: gssapi-with-mic Message-ID: <27490000.1062778373@mariner.pc.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit OK; I _think_ we may actually have concensus this time. So, here's a concrete proposal for what the changes to the spec should look like. Hopefully this will be enough for people to comment on and implement from, until I can post some real text and submit a draft... * In section 3 of the -06 document, which describes "gssapi" userauth: - Rename the mechanism from "gssapi" to "gssapi-with-mic" - When calling GSS_Init_sec_context, the client MUST set integ_req_flag - If integ_avail is false, send SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE - If integ_avail is true, send SSH_MSG_USERAUTH_GSSAPI_MIC (see below). - The server MUST reject the authentication if it gets the wrong message. - The server MAY reject authentication anyway if integ_avail is false. The SSH_MSG_USERAUTH_GSSAPI_MIC message looks like this: byte SSH_MSG_USERAUTH_GSSAPI_MIC string MIC The MIC is the result of calling GSS_GetMIC on the following: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-with-mic" The message number for SSH_MSG_USERAUTH_GSSAPI_MIC is 66. I know this is a little different from what Joseph proposed -- what I describe actually involves using a different message depending on whether integrity is available, rather than sending the same message with a possibly empty MIC string. I did this to try to make life easier for people who are also implementing "gssapi" -- except for the method name, the exchange for "gssapi" is exactly the same as for "gssapi-with-mic" when integrity is not supported. That should make it easier to implement both with common code, if desired, and it also retains some semblance of documentation of the old method in the document. If people would rather see SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away completely, we can use the empty-MIC-string approach instead. * Section 4, describing external-keyx, is replaced entirely. The new mechanism is called "gssapi-keyex", and consists of a single message: byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-keyex" string MIC The MIC is computed by calling GSS_GetMIC using the context from _initial_ key exchange. The context from a rekey is never used; if the initial key exchange was not GSSAPI-based, then this method cannot be used. The MIC is computed over the following: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-keyex" Reasonable? -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 12:51:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05286 for ; Fri, 5 Sep 2003 12:51:11 -0400 (EDT) Received: (qmail 23798 invoked by uid 605); 5 Sep 2003 16:51:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23791 invoked from network); 5 Sep 2003 16:51:14 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 5 Sep 2003 16:51:14 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2003 10:03:36 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h85GpB8e022515; Fri, 5 Sep 2003 09:51:12 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.112.240]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Sep 2003 09:55:30 -0700 From: "Joseph Salowey" To: "'Jeffrey Hutzelman'" , Subject: RE: gssapi-with-mic Date: Fri, 5 Sep 2003 09:51:10 -0700 Message-ID: <023201c373cd$e934afe0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <27490000.1062778373@mariner.pc.cs.cmu.edu> X-OriginalArrivalTime: 05 Sep 2003 16:55:31.0100 (UTC) FILETIME=[83F785C0:01C373CE] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi Jeffrey, I think this looks reasonable. Just one nit, I assume integ_avail would have to be checked when GSS_S_COMPLETE is returned since some mechanisms may not have integrity services available until then. I don't want to document or encourage "gssapi", but I don't see anything wrong with reusing the message format to make the transition easier. Joe > > * In section 3 of the -06 document, which describes "gssapi" userauth: > - Rename the mechanism from "gssapi" to "gssapi-with-mic" > - When calling GSS_Init_sec_context, the client MUST set > integ_req_flag > - If integ_avail is false, send > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE > - If integ_avail is true, send SSH_MSG_USERAUTH_GSSAPI_MIC > (see below). > - The server MUST reject the authentication if it gets the > wrong message. > - The server MAY reject authentication anyway if integ_avail is false. > > The SSH_MSG_USERAUTH_GSSAPI_MIC message looks like this: > > byte SSH_MSG_USERAUTH_GSSAPI_MIC > string MIC > > The MIC is the result of calling GSS_GetMIC on the following: > > string session identifier > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-with-mic" > > The message number for SSH_MSG_USERAUTH_GSSAPI_MIC is 66. > I know this is a little different from what Joseph proposed -- what I > describe actually involves using a different message > depending on whether > integrity is available, rather than sending the same message with a > possibly empty MIC string. I did this to try to make life easier for > people who are also implementing "gssapi" -- except for the > method name, > the exchange for "gssapi" is exactly the same as for > "gssapi-with-mic" when > integrity is not supported. That should make it easier to > implement both > with common code, if desired, and it also retains some semblance of > documentation of the old method in the document. If people > would rather > see SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away > completely, we can > use the empty-MIC-string approach instead. > > > * Section 4, describing external-keyx, is replaced entirely. The new > mechanism is called "gssapi-keyex", and consists of a single message: > > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-keyex" > string MIC > > The MIC is computed by calling GSS_GetMIC using the context > from _initial_ > key exchange. The context from a rekey is never used; if the > initial key > exchange was not GSSAPI-based, then this method cannot be > used. The MIC is > computed over the following: > > string session identifier > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-keyex" > > > > Reasonable? > > -- Jeff > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:04:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05931 for ; Fri, 5 Sep 2003 13:04:11 -0400 (EDT) Received: (qmail 2454 invoked by uid 605); 5 Sep 2003 17:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2445 invoked from network); 5 Sep 2003 17:04:13 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 17:04:13 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2170205 for ietf-ssh@NetBSD.org; Fri, 05 Sep 2003 11:04:13 -0600 Message-ID: <3F58C20C.5020702@vandyke.com> Date: Fri, 05 Sep 2003 11:04:12 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: new sftp draft gotta come soon: summary Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Well, the sftp draft has expired, so I guess I can't let the priority of a revision keep getting bumped down anymore :-) So, here are what I think of as open issues: - A bit or flag in the attribs to reflect if the file should be hidden. (I was supposed to put this in last time, but didn't-- ) - A bit or flag in the attribs to reflect 'readonly' status -- this readonly status is an advisory as opposed enforced readonly. (Windows is the operating system that does this.) - A way to specify how to access the file during file open (should match up with access modes in ACLs.) Currently, it is hard to know with what access a file should be opened-- what if the client comes back and does a fsetstat and tries to write an ACL? - A way to control file sharing during file open (operating systems that don't support it ignore it?) - We never reached consensus about case-sensitivity. (See next email for details.) - Performance enhancments. (See next email for details.) - Security considerations section - Normative vs. non-normative references - Change of sftp rename command (see next email for details) Are there any other issues that anyone wants fixed or flogged to death to make sure everyone agrees? You are implementing and sftp server on the latest and greatest bi-endian 1024-bit super-opper-dupper computer running your very own custom operating system and you users want to be able to x when they transfer files and sftp doesn't make it possible. You are implementing a filesystem redirector for you super-dupper operating system and SFTP makes Z a very big pain for you. This is your last chance :-) We're gonna ship this one and do last call. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:04:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05967 for ; Fri, 5 Sep 2003 13:04:22 -0400 (EDT) Received: (qmail 2677 invoked by uid 605); 5 Sep 2003 17:04:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2568 invoked from network); 5 Sep 2003 17:04:16 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 17:04:16 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2170211 for ietf-ssh@NetBSD.org; Fri, 05 Sep 2003 11:04:15 -0600 Message-ID: <3F58C20F.3000506@vandyke.com> Date: Fri, 05 Sep 2003 11:04:15 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Case sensitivity on sftp servers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We never reached consensus on the issue of the server advertising whether or not files where case sensitive or not. I think it is a good idea for the server to tell the client about case sensitivity because: o For globbing purposes, the client may need to know, depending on how the user wants to operate, whether a* matches Alphabet.txt on the server. I claim we are not smart enough to know all the ways people will want to use SFTP and therefor not smart enough to say that they will all be happy with globbing that uses the case rules of their client. o When transfering files between a client and server with different case properties, the client may wish to warn the client about problems (instead of overwriting just transfered data or giving the user an overwrite prompt.) The client might also wish to help the user resolve the problems (automatic renaming algorithms, or some kind of conflict resolution interface.) These kinds of things would be made easier by the client understanding that two different files on the server have the same name on the client. Or, two different files on the client have the same name when transfered to the server. Do we want to solve these problems in the sftp draft? VanDyke has solved these problems between our own clients and servers using the following extension: string "default-fs-attribs@vandyke.com" string attrib-packet uint32 file-system-attribute-mask string illegal-characters [UTF8] uint32 reserved-name-count string reserved-name[1] [UTF8] ... string reserved-name[reserved-name-count] [UTF8] file-system-attribute-mask Any combination of the following: SFTP_FSATTR_CASE_PRESERVED = 1 SFTP_FSATTR_CASE_SENSITIVE = 2 illegal-characters Characters that can not be used in a file or directory name. reserved-name-count reserved-name Names that cna not be used for a file or directory. For example, under WinNT, these include COM1, COM2, etc. Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:04:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06002 for ; Fri, 5 Sep 2003 13:04:40 -0400 (EDT) Received: (qmail 2745 invoked by uid 605); 5 Sep 2003 17:04:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2674 invoked from network); 5 Sep 2003 17:04:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 17:04:19 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2170209 for ietf-ssh@NetBSD.org; Fri, 05 Sep 2003 11:04:18 -0600 Message-ID: <3F58C211.8050605@vandyke.com> Date: Fri, 05 Sep 2003 11:04:17 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Sftp: performance enhancing changes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We had a discussion of sftp performance. I don't think we really reached an consensus about a change. The following things were brought up: o Ignoring channel window makes for a screaming sftp transfer. (unacceptable, breaks multiplexing.) o I proposed a new SSH_FXP_MULTI_READ that would make it easier to do large data transfers. o An implementation hints section with some verbage about issuing multiple simultaneous read and write requests to obtain maxmimum performance. Do we want to do any of these things. (Well, the first is unacceptable of course.) Here is the proposed MULTI_READ request: > However, in order to facilitate writing > higher performing SFTP clients, I have > considered that it might make sense to > add a second read command to SFTP, which > allowed reads of any size, but which can > result in multiple data packets, culminating > in a final status packet. > > I.E. > Client: SSH_FXP_MULTI_READ: req-id=243, offset=0, bytes=4,000,0000 > Server: SSH_FXP_DATA: req-id=243, 64K > Server: SSH_FXP_DATA: req-id=243, 64K > Server: SSH_FXP_DATA: req-id=243, 64K > ... > Server: SSH_FXP_DATA: req-id=243, 64K > Server: SSH_FXP_STATUS: req-id=243, SUCCESS > > or > Server: SSH_FXP_DATA: req-id=243, 64K > Server: SSH_FXP_DATA: req-id=243, 64K > Server: SSH_FXP_STATUS: req-id=243, EOF > > This would allow a client to request the entire > file in a single read operation without requiring > the server to allocate huge buffers or being > vulnerable to corner cases (such as mid-read > truncation.) So, what do we want to do? Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:05:08 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06032 for ; Fri, 5 Sep 2003 13:05:08 -0400 (EDT) Received: (qmail 2838 invoked by uid 605); 5 Sep 2003 17:04:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2758 invoked from network); 5 Sep 2003 17:04:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 17:04:21 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2170208 for ietf-ssh@NetBSD.org; Fri, 05 Sep 2003 11:04:20 -0600 Message-ID: <3F58C213.4090606@vandyke.com> Date: Fri, 05 Sep 2003 11:04:19 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Sftp rename: 2 proposals Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I made this proposal, but after not being able to find it, I realized I screwed up sending it and it didn't ever make it to the list: All right, how about the following change: 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] uint32 flags 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. flags is 0 or a combination of SSH_FXP_RENAME_OVERWRITE 0x00000001 SSH_FXP_RENAME_ATOMIC 0x00000002 SSH_FXP_RENAME_NATIVE 0x00000004 SSH_FXP_RENAME_COPY_OK 0x00000008 If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already exists a file with the name specified by newpath, the server MUST respond with SSH_FX_FILE_ALREADY_EXISTS. If flags includes SSH_FXP_RENAME_ATOMIC, and the destination file already exists, it is replaced in an atomic fashion. I.e., there is no observable instance in time where the destination file does not exist. SSH_FXP_RENAME_ATOMIC implies SSH_FXP_RENAME_OVERWRITE. There may, however, be some span of time where both the source and destination file exist. SSH_FXP_RENAME_ATOMIC has no bearing on the source file. If flags includes SSH_FXP_RENAME_ATOMIC and the server cannot replace the destination in an atomic fashion, then the server MUST respond with SSH_FX_OP_UNSUPPORTED. Because some servers cannot provide atomic rename, clients should only specify atomic rename if correct operation requires it. If SSH_FXP_RENAME_OVERWRITE is specified, the server MAY preform an atomic rename even if it is not requested. If flags includes SSH_FXP_RENAME_NATIVE, the server is free to do the rename operation in whatever fashion it deems appropriate. Other flag values are considered hints as to desired behavior, but not requirements. If flags includes SSH_FXP_RENAME_COPY_OK, the server MAY preform a copy / delete operation in order to complete the operation. If an atomic rename is also requested, the server may only preform this sequence if it can do so in an atomic fashion for the destination file. The server may 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 message. The other proposal is this (from Martin Pool, mbp@samba.org): > I think the fact that SSH_FXP_RENAME is impossible to reliably > implemented on Unix is a serious problem. Secondarily it is a shame > that it prevents use of the atomic-rename Unix idiom. > > I would like to suggest that the phrasing be changed to > > The server MAY return SSH_FX_FILE_ALREADY_EXISTS if there exists a > file with the name specified by newpath. > > Clients which wish to always replace the path without knowing the > server filesystem can precede the rename operation with an attempt to > delete the destination file. That does not seem to be an undue > burden. > > Clients which know the server is Unix and which wish to take advantage > of atomic replace can do so. I believe this proposal has a couple of issues: o It is not possible to know if the server is unix (and I think, in general, it is a bad idea to make decisions based on OS type.) o If the client does _not_ wish to have the file replaced, it must stat the file and wait for the response before preceeding. o As mentioned above, if the client wishes the file to always be overwritten, it must delete the destination, and then do the rename, but even that may _still_ fail if something comes along and recreates the file in the interim. (Imagine a system where the file must exist, and so there is a monitor program which recreates the file if it is deleted. Farfetched? Maybe. Possible? Definitely.) I think it is far better for the client to be able to specify the behavior they want on the rename. Most clients are probably happy with whatever the server does natively. -- I believe both of these proposals require sftp v5; mine certainly does, but Martin's changes the semantics of an existing operation sufficiently that I believe we should change the version number. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:18:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06881 for ; Fri, 5 Sep 2003 13:18:29 -0400 (EDT) Received: (qmail 11161 invoked by uid 605); 5 Sep 2003 17:18:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11154 invoked from network); 5 Sep 2003 17:18:31 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 5 Sep 2003 17:18:31 -0000 Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa30570; 5 Sep 2003 13:18 EDT Date: Fri, 05 Sep 2003 13:18:08 -0400 From: Jeffrey Hutzelman To: Joseph Salowey , ietf-ssh@NetBSD.org Subject: RE: gssapi-with-mic Message-ID: <33370000.1062782288@mariner.pc.cs.cmu.edu> In-Reply-To: <023201c373cd$e934afe0$0200000a@amer.cisco.com> References: <023201c373cd$e934afe0$0200000a@amer.cisco.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, September 05, 2003 09:51:10 -0700 Joseph Salowey wrote: > Hi Jeffrey, > > I think this looks reasonable. Just one nit, I assume integ_avail would > have to be checked when GSS_S_COMPLETE is returned since some mechanisms > may not have integrity services available until then. Yes, that's the idea. The text will be clear on this, as it is for key exchange. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:21:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07055 for ; Fri, 5 Sep 2003 13:21:17 -0400 (EDT) Received: (qmail 12993 invoked by uid 605); 5 Sep 2003 17:21:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12986 invoked from network); 5 Sep 2003 17:21:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 17:21:19 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2170374; Fri, 05 Sep 2003 11:21:18 -0600 Message-ID: <3F58C60E.5090201@vandyke.com> Date: Fri, 05 Sep 2003 11:21:18 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org Subject: Re: gssapi-with-mic References: <27490000.1062778373@mariner.pc.cs.cmu.edu> In-Reply-To: <27490000.1062778373@mariner.pc.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Looks good to me. - Joseph Jeffrey Hutzelman wrote: > OK; I _think_ we may actually have concensus this time. So, here's a > concrete proposal for what the changes to the spec should look like. > Hopefully this will be enough for people to comment on and implement > from, until I can post some real text and submit a draft... > > * In section 3 of the -06 document, which describes "gssapi" userauth: > - Rename the mechanism from "gssapi" to "gssapi-with-mic" > - When calling GSS_Init_sec_context, the client MUST set integ_req_flag > - If integ_avail is false, send SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE > - If integ_avail is true, send SSH_MSG_USERAUTH_GSSAPI_MIC (see below). > - The server MUST reject the authentication if it gets the wrong message. > - The server MAY reject authentication anyway if integ_avail is false. > > The SSH_MSG_USERAUTH_GSSAPI_MIC message looks like this: > > byte SSH_MSG_USERAUTH_GSSAPI_MIC > string MIC > > The MIC is the result of calling GSS_GetMIC on the following: > > string session identifier > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-with-mic" > > The message number for SSH_MSG_USERAUTH_GSSAPI_MIC is 66. > I know this is a little different from what Joseph proposed -- what I > describe actually involves using a different message depending on > whether integrity is available, rather than sending the same message > with a possibly empty MIC string. I did this to try to make life easier > for people who are also implementing "gssapi" -- except for the method > name, the exchange for "gssapi" is exactly the same as for > "gssapi-with-mic" when integrity is not supported. That should make it > easier to implement both with common code, if desired, and it also > retains some semblance of documentation of the old method in the > document. If people would rather see > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away completely, we can use > the empty-MIC-string approach instead. > > > * Section 4, describing external-keyx, is replaced entirely. The new > mechanism is called "gssapi-keyex", and consists of a single message: > > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-keyex" > string MIC > > The MIC is computed by calling GSS_GetMIC using the context from > _initial_ key exchange. The context from a rekey is never used; if the > initial key exchange was not GSSAPI-based, then this method cannot be > used. The MIC is computed over the following: > > string session identifier > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-keyex" > > > > Reasonable? > > -- Jeff > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:40:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08208 for ; Fri, 5 Sep 2003 13:40:08 -0400 (EDT) Received: (qmail 23635 invoked by uid 605); 5 Sep 2003 17:40:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23593 invoked from network); 5 Sep 2003 17:40:09 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Sep 2003 17:40:09 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 13:40:07 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC20E@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@NetBSD.org Subject: RE: Case sensitivity on sftp servers Date: Fri, 5 Sep 2003 13:39:58 -0400 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 Though I agree that specifying case sensitivity may be useful, I think that specifying it on a server wide basis is too broad. The server may offer several file systems and some of these may not preserve case, while others may preserve case but not be case sensitive, and still other may preserve case and be case sensitive. The server may also have the option of allowing the client to specify whether or not file operations are case sensitive on a file system that preserves case. It may be necessary to specify a method of obtaining the file systems available and their characteristics (Read Only, Case Preserving, Case Sensitive, etc.) ---------------------- Richard Whalen Process Software 508-879-6994x261 -----Original Message----- From: Joseph Galbraith [mailto:galb@vandyke.com] Sent: Friday, September 05, 2003 1:04 PM To: ietf-ssh@NetBSD.org Subject: Case sensitivity on sftp servers We never reached consensus on the issue of the server advertising whether or not files where case sensitive or not. I think it is a good idea for the server to tell the client about case sensitivity because: o For globbing purposes, the client may need to know, depending on how the user wants to operate, whether a* matches Alphabet.txt on the server. I claim we are not smart enough to know all the ways people will want to use SFTP and therefor not smart enough to say that they will all be happy with globbing that uses the case rules of their client. o When transfering files between a client and server with different case properties, the client may wish to warn the client about problems (instead of overwriting just transfered data or giving the user an overwrite prompt.) The client might also wish to help the user resolve the problems (automatic renaming algorithms, or some kind of conflict resolution interface.) These kinds of things would be made easier by the client understanding that two different files on the server have the same name on the client. Or, two different files on the client have the same name when transfered to the server. Do we want to solve these problems in the sftp draft? VanDyke has solved these problems between our own clients and servers using the following extension: string "default-fs-attribs@vandyke.com" string attrib-packet uint32 file-system-attribute-mask string illegal-characters [UTF8] uint32 reserved-name-count string reserved-name[1] [UTF8] ... string reserved-name[reserved-name-count] [UTF8] file-system-attribute-mask Any combination of the following: SFTP_FSATTR_CASE_PRESERVED = 1 SFTP_FSATTR_CASE_SENSITIVE = 2 illegal-characters Characters that can not be used in a file or directory name. reserved-name-count reserved-name Names that cna not be used for a file or directory. For example, under WinNT, these include COM1, COM2, etc. Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 13:56:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09169 for ; Fri, 5 Sep 2003 13:56:00 -0400 (EDT) Received: (qmail 4139 invoked by uid 605); 5 Sep 2003 17:56:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4132 invoked from network); 5 Sep 2003 17:56:01 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 5 Sep 2003 17:56:01 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h85HtxSU009055; Sat, 6 Sep 2003 05:55:59 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h85HuRZ22956; Sat, 6 Sep 2003 05:56:27 +1200 Date: Sat, 6 Sep 2003 05:56:27 +1200 Message-Id: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: >o Ignoring channel window makes for a screaming > sftp transfer. (unacceptable, breaks multiplexing.) It's only unacceptable if you're actually doing multiplexing. If you're just using SFTP as a secure FTP replacement (which is what many people seem to be using it for), it's a simple, quick fix for the SFTP performance problems. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 14:23:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10859 for ; Fri, 5 Sep 2003 14:23:59 -0400 (EDT) Received: (qmail 21516 invoked by uid 605); 5 Sep 2003 18:24:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21509 invoked from network); 5 Sep 2003 18:24:00 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 5 Sep 2003 18:24:00 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h85INpSt009738; Fri, 5 Sep 2003 11:23:52 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h85INptK018405; Fri, 5 Sep 2003 14:23:51 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h85INpue025039; Fri, 5 Sep 2003 14:23:51 -0400 (EDT) Message-Id: <200309051823.h85INpue025039@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes In-Reply-To: Your message of "Sat, 06 Sep 2003 05:56:27 +1200." <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Fri, 05 Sep 2003 14:23:51 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > >o Ignoring channel window makes for a screaming > > sftp transfer. (unacceptable, breaks multiplexing.) > > It's only unacceptable if you're actually doing multiplexing. If you're just > using SFTP as a secure FTP replacement (which is what many people seem to be > using it for), it's a simple, quick fix for the SFTP performance problems. My understanding based on reading the earlier discussion is that this is a red herring -- the fix (which doesn't involve violating the specs) is to pipeline read/write requests and ensure the channel window is substantially larger than the TCP window). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 14:27:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11039 for ; Fri, 5 Sep 2003 14:27:09 -0400 (EDT) Received: (qmail 23348 invoked by uid 605); 5 Sep 2003 18:27:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23336 invoked from network); 5 Sep 2003 18:27:11 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Sep 2003 18:27:11 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 14:27:10 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: Re: Publickey subsystem draft Date: Fri, 5 Sep 2003 14:27:07 -0400 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 I am looking into implementing the Public-Key Subsystem and I've come across a bit of a problem that I need to solve before I can continue. Our implementation is built upon the implementation from SSH.COM. In this implementation there is a file that contains a list of the files that contain the keys, with one key per file. Implementing the "list" operation is no problem: read the file that contains the list of key files and then send the information from each key file. The hard part comes with the "add" and "remove" operations. Since each key is stored in a separate file, there needs to be a name for this file. The current draft does not contain a "name" for a key that could be used to specify the file that the key is stored in. ---------------------- Richard Whalen Process Software 508-879-6994x261 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 14:31:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11234 for ; Fri, 5 Sep 2003 14:31:12 -0400 (EDT) Received: (qmail 25689 invoked by uid 605); 5 Sep 2003 18:31:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25681 invoked from network); 5 Sep 2003 18:31:13 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 5 Sep 2003 18:31:13 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01L0B0I11O6G8WW0NP@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 05 Sep 2003 12:31:03 -0700 (MST) Date: Fri, 05 Sep 2003 12:30:05 -0600 From: "Dan O'Reilly" Subject: Re: Publickey subsystem draft In-reply-to: <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.c om> X-Sender: oreilly@raptor.psccos.com To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Message-id: <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Why not use the methodology used by SSH-KEYGEN? It's simple to implement and would be in keeping with that used on the server already. At 12:27 PM 9/5/2003, Richard Whalen wrote: >I am looking into implementing the Public-Key Subsystem and I've come across >a bit of a problem that I need to solve before I can continue. > >Our implementation is built upon the implementation from SSH.COM. In this >implementation there is a file that contains a list of the files that >contain the keys, with one key per file. > >Implementing the "list" operation is no problem: read the file that contains >the list of key files and then send the information from each key file. > >The hard part comes with the "add" and "remove" operations. Since each key >is stored in a separate file, there needs to be a name for this file. The >current draft does not contain a "name" for a key that could be used to >specify the file that the key is stored in. > >---------------------- >Richard Whalen >Process Software >508-879-6994x261 ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 15:47:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15440 for ; Fri, 5 Sep 2003 15:47:28 -0400 (EDT) Received: (qmail 17705 invoked by uid 605); 5 Sep 2003 19:47:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17697 invoked from network); 5 Sep 2003 19:47:30 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 19:47:30 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2171102; Fri, 05 Sep 2003 13:47:29 -0600 Message-ID: <3F58E851.2090204@vandyke.com> Date: Fri, 05 Sep 2003 13:47:29 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Richard Whalen CC: "'ietf-ssh@netbsd.org'" Subject: Re: Publickey subsystem draft References: <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Our server is file based as well (presence in the directory authorizes the key for us.) For add, we autogenerate a name (using the fingerprint of the key.) For remove, we iterate through each canidate file until we find the one that matches, and then we delete that file. You'll have to read each key file in the list file until you find the one that the user is trying to remove. I'm not sure whether you should just remove the entry or whether you should remove both the entry and the file. We deliberately avoided assuming a file based implementation in the draft. (What if you used a database to store keys?) Thanks, - Joseph Richard Whalen wrote: > I am looking into implementing the Public-Key Subsystem and I've come across > a bit of a problem that I need to solve before I can continue. > > Our implementation is built upon the implementation from SSH.COM. In this > implementation there is a file that contains a list of the files that > contain the keys, with one key per file. > > Implementing the "list" operation is no problem: read the file that contains > the list of key files and then send the information from each key file. > > The hard part comes with the "add" and "remove" operations. Since each key > is stored in a separate file, there needs to be a name for this file. The > current draft does not contain a "name" for a key that could be used to > specify the file that the key is stored in. > > ---------------------- > Richard Whalen > Process Software > 508-879-6994x261 > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 16:03:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16106 for ; Fri, 5 Sep 2003 16:03:42 -0400 (EDT) Received: (qmail 29064 invoked by uid 605); 5 Sep 2003 20:03:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29057 invoked from network); 5 Sep 2003 20:03:45 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 20:03:45 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2171113; Fri, 05 Sep 2003 14:03:44 -0600 Message-ID: <3F58EC1F.4040406@vandyke.com> Date: Fri, 05 Sep 2003 14:03:43 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes References: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> In-Reply-To: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Joseph Galbraith writes: >>o Ignoring channel window makes for a screaming >> sftp transfer. (unacceptable, breaks multiplexing.) > > It's only unacceptable if you're actually doing multiplexing. If you're just > using SFTP as a secure FTP replacement (which is what many people seem to be > using it for), it's a simple, quick fix for the SFTP performance problems. It is unacceptable because draft-ietf-secsh-connect-17 states in section 3.2: > The maximum amount of data allowed is the current window size. > The window size is decremented by the amount of data sent. Both > parties MAY ignore all extra data sent after the allowed window is > empty. And our server _will_ drop data that exceeds the channel window. The sftp draft can't override this rule, and I don't think we are going to change the connection draft. (To be honest I don't think we should either.) Sorry, I should have been clearer on why I thought it was unacceptable. In addition, proper management of packet size and channel windows can mean that there is no or very little overhead from obeying the rules. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 16:37:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17805 for ; Fri, 5 Sep 2003 16:37:42 -0400 (EDT) Received: (qmail 19452 invoked by uid 605); 5 Sep 2003 20:37:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19445 invoked from network); 5 Sep 2003 20:37:44 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Sep 2003 20:37:44 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2171291; Fri, 05 Sep 2003 14:37:44 -0600 Message-ID: <3F58F417.4010306@vandyke.com> Date: Fri, 05 Sep 2003 14:37:43 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Richard Whalen CC: "'Joseph Galbraith'" , ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers References: <63D30D6E10CFD11190A90000F805FE86051AC20E@lespaul.process.com> In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC20E@lespaul.process.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Though I agree that specifying case sensitivity may be useful, I think that > specifying it on a server wide basis is too broad. > > The server may offer several file systems and some of these may not preserve > case, while others may preserve case but not be case sensitive, and still > other may preserve case and be case sensitive. > > The server may also have the option of allowing the client to specify > whether or not file operations are case sensitive on a file system that > preserves case. > > It may be necessary to specify a method of obtaining the file systems > available and their characteristics (Read Only, Case Preserving, Case > Sensitive, etc.) You raise a good point--- hmmm... let's try this on for size: new attrib bit: SSH_FILEXFER_ATTR_FILESYSTEM string filesystem-name SSH_FILEXFER_ATTR_FILESYSTEM is only sent by the server if the client requested it by including in the flags mask during readdir or stat operation and the file in question is a directory. filesystem-name is a handle that can be passed back to the server using the "read-filesystem-attributes" It need not be human readable. -- byte SSH_FXP_EXTENDED uint32 request-id string "read-filesystem-attributes" string filesystem-name byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint32 file-system attribute flags CASE_SENSITIVE CASE_PRESERVITIVE CASE_OPTIONAL string-utf8 invalid-chars uint32 reserved-name-count string reserved-name[1..reserved-name-count] And, a new flag bit in in the modes during open to specify that the filename should be case sensitive or case insensitive. If the server can't comply, it return OP_UNSUPPORTED. What do you think? I think I keep the "default-file-attributes" and then the filesystem only need be sent if it is different from the default. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 17:14:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19555 for ; Fri, 5 Sep 2003 17:14:53 -0400 (EDT) Received: (qmail 12269 invoked by uid 605); 5 Sep 2003 21:14:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12262 invoked from network); 5 Sep 2003 21:14:51 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Sep 2003 21:14:51 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 17:14:50 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" Cc: ietf-ssh@NetBSD.org Subject: RE: Case sensitivity on sftp servers Date: Fri, 5 Sep 2003 17:14:41 -0400 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 I think that this will work. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Friday, September 05, 2003 4:38 PM To: Richard Whalen Cc: 'Joseph Galbraith'; ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers > Though I agree that specifying case sensitivity may be useful, I think that > specifying it on a server wide basis is too broad. > > The server may offer several file systems and some of these may not preserve > case, while others may preserve case but not be case sensitive, and still > other may preserve case and be case sensitive. > > The server may also have the option of allowing the client to specify > whether or not file operations are case sensitive on a file system that > preserves case. > > It may be necessary to specify a method of obtaining the file systems > available and their characteristics (Read Only, Case Preserving, Case > Sensitive, etc.) You raise a good point--- hmmm... let's try this on for size: new attrib bit: SSH_FILEXFER_ATTR_FILESYSTEM string filesystem-name SSH_FILEXFER_ATTR_FILESYSTEM is only sent by the server if the client requested it by including in the flags mask during readdir or stat operation and the file in question is a directory. filesystem-name is a handle that can be passed back to the server using the "read-filesystem-attributes" It need not be human readable. -- byte SSH_FXP_EXTENDED uint32 request-id string "read-filesystem-attributes" string filesystem-name byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint32 file-system attribute flags CASE_SENSITIVE CASE_PRESERVITIVE CASE_OPTIONAL string-utf8 invalid-chars uint32 reserved-name-count string reserved-name[1..reserved-name-count] And, a new flag bit in in the modes during open to specify that the filename should be case sensitive or case insensitive. If the server can't comply, it return OP_UNSUPPORTED. What do you think? I think I keep the "default-file-attributes" and then the filesystem only need be sent if it is different from the default. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 18:46:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24493 for ; Fri, 5 Sep 2003 18:46:34 -0400 (EDT) Received: (qmail 2346 invoked by uid 605); 5 Sep 2003 22:46:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2321 invoked from network); 5 Sep 2003 22:46:35 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 5 Sep 2003 22:46:35 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h85MkQ0t022593; Fri, 5 Sep 2003 15:46:26 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h85MkPi7011642; Fri, 5 Sep 2003 16:46:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h85MgmQx014840; Fri, 5 Sep 2003 15:42:48 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h85MgkMC014839; Fri, 5 Sep 2003 15:42:46 -0700 (PDT) Date: Fri, 5 Sep 2003 15:42:46 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Joseph Salowey , ietf-ssh@NetBSD.org Subject: Re: gssapi-with-mic Message-ID: <20030905224242.GA14832@binky.central.sun.com> References: <023201c373cd$e934afe0$0200000a@amer.cisco.com> <33370000.1062782288@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33370000.1062782288@mariner.pc.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Sep 05, 2003 at 01:18:08PM -0400, Jeffrey Hutzelman wrote: > > > On Friday, September 05, 2003 09:51:10 -0700 Joseph Salowey > wrote: > > >Hi Jeffrey, > > > >I think this looks reasonable. Just one nit, I assume integ_avail would > >have to be checked when GSS_S_COMPLETE is returned since some mechanisms > >may not have integrity services available until then. > > Yes, that's the idea. The text will be clear on this, as it is for key > exchange. There's always PROT_READY w/ partially established contexts - that can save a 1/2 round-trip. I'm not sure that I'd actually recommend this though. We have to work out some things about this in the KRB WG wrt the new Kerberos V GSS-API mechanism. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 20:20:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27679 for ; Fri, 5 Sep 2003 20:20:38 -0400 (EDT) Received: (qmail 16697 invoked by uid 605); 6 Sep 2003 00:20:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16686 invoked from network); 6 Sep 2003 00:20:36 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 6 Sep 2003 00:20:36 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h860KXUH004569; Fri, 5 Sep 2003 18:20:33 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h860KWi7006943; Fri, 5 Sep 2003 18:20:32 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h860GtQx015000; Fri, 5 Sep 2003 17:16:55 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h860GrMr014999; Fri, 5 Sep 2003 17:16:53 -0700 (PDT) Date: Fri, 5 Sep 2003 17:16:53 -0700 From: Nicolas Williams To: Peter Gutmann Cc: galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030906001649.GA14995@binky.central.sun.com> References: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Sep 06, 2003 at 05:56:27AM +1200, Peter Gutmann wrote: > Joseph Galbraith writes: > > >o Ignoring channel window makes for a screaming > > sftp transfer. (unacceptable, breaks multiplexing.) > > It's only unacceptable if you're actually doing multiplexing. If you're just > using SFTP as a secure FTP replacement (which is what many people seem to be > using it for), it's a simple, quick fix for the SFTP performance problems. No. The consensus of the SFTP perf thread was, IIRC, that there is no handbrake in either SSHv2 or SFTP and that clients and servers should be smart about using larger windows for the SFTP sub-system. Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 5 23:09:31 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04343 for ; Fri, 5 Sep 2003 23:09:30 -0400 (EDT) Received: (qmail 12620 invoked by uid 605); 6 Sep 2003 03:09:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12613 invoked from network); 6 Sep 2003 03:09:33 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 6 Sep 2003 03:09:33 -0000 Received: by guinness.cs.stevens-tech.edu (Postfix, from userid 3330) id 88E3C14169C; Fri, 5 Sep 2003 23:09:32 -0400 (EDT) Date: Fri, 5 Sep 2003 23:09:32 -0400 From: Thor Simon To: ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030905230932.A788425@cs.stevens-tech.edu> References: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> <20030906001649.GA14995@binky.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: <20030906001649.GA14995@binky.central.sun.com>; from Nicolas.Williams@sun.com on Fri, Sep 05, 2003 at 05:16:53PM -0700 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Sep 05, 2003 at 05:16:53PM -0700, Nicolas Williams wrote: > > No. The consensus of the SFTP perf thread was, IIRC, that there is no > handbrake in either SSHv2 or SFTP and that clients and servers should be > smart about using larger windows for the SFTP sub-system. There are other applications that display horrific performance characteristics over at least some widespread SSHv2 implementations. One notable one is rsync. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 6 17:10:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05064 for ; Sat, 6 Sep 2003 17:10:49 -0400 (EDT) Received: (qmail 21837 invoked by uid 605); 6 Sep 2003 21:10:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21830 invoked from network); 6 Sep 2003 21:10:49 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 6 Sep 2003 21:10:49 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h86LAj0t009449; Sat, 6 Sep 2003 14:10:45 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h86LAji7005196; Sat, 6 Sep 2003 15:10:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h86L77Qx015402; Sat, 6 Sep 2003 14:07:07 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h86L76dW015401; Sat, 6 Sep 2003 14:07:06 -0700 (PDT) Date: Sat, 6 Sep 2003 14:07:06 -0700 From: Nicolas Williams To: Thor Simon Cc: ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030906210703.GA15396@binky.central.sun.com> References: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> <20030906001649.GA14995@binky.central.sun.com> <20030905230932.A788425@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030905230932.A788425@cs.stevens-tech.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Sep 05, 2003 at 11:09:32PM -0400, Thor Simon wrote: > On Fri, Sep 05, 2003 at 05:16:53PM -0700, Nicolas Williams wrote: > > > > No. The consensus of the SFTP perf thread was, IIRC, that there is no > > handbrake in either SSHv2 or SFTP and that clients and servers should be > > smart about using larger windows for the SFTP sub-system. > > There are other applications that display horrific performance characteristics > over at least some widespread SSHv2 implementations. One notable one is > rsync. This may be due to the SSHv2 client and/or server implementations setting small window sizes for what they think is an interactive session. I suggest that you bring this up with the implementor, that you try not using ptys and/or that you try making rsync a sub-system. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 6 17:25:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06146 for ; Sat, 6 Sep 2003 17:25:22 -0400 (EDT) Received: (qmail 28813 invoked by uid 605); 6 Sep 2003 21:25:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28805 invoked from network); 6 Sep 2003 21:25:24 -0000 Received: from glenlivet.cs.stevens-tech.edu (155.246.89.62) by mail.netbsd.org with SMTP; 6 Sep 2003 21:25:24 -0000 Received: by glenlivet.cs.stevens-tech.edu (Postfix, from userid 3330) id CE3DC7B989; Sat, 6 Sep 2003 17:25:19 -0400 (EDT) Date: Sat, 6 Sep 2003 17:25:19 -0400 From: Thor Simon To: ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030906212519.GA9259@cs.stevens-tech.edu> References: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> <20030906001649.GA14995@binky.central.sun.com> <20030905230932.A788425@cs.stevens-tech.edu> <20030906210703.GA15396@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030906210703.GA15396@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Sep 06, 2003 at 02:07:06PM -0700, Nicolas Williams wrote: > On Fri, Sep 05, 2003 at 11:09:32PM -0400, Thor Simon wrote: > > On Fri, Sep 05, 2003 at 05:16:53PM -0700, Nicolas Williams wrote: > > > > > > No. The consensus of the SFTP perf thread was, IIRC, that there is no > > > handbrake in either SSHv2 or SFTP and that clients and servers should be > > > smart about using larger windows for the SFTP sub-system. > > > > There are other applications that display horrific performance characteristics > > over at least some widespread SSHv2 implementations. One notable one is > > rsync. > > This may be due to the SSHv2 client and/or server implementations > setting small window sizes for what they think is an interactive > session. I suggest that you bring this up with the implementor, that Uh, what makes you think that any common Unix implementation would use ptys (or decide the session is interactive) when handed a remote command to execute on the command line? Certainly I cannot think of one that does (this would also fly in the face of A) common sense and B) what legacy rsh did and C) what the original F-Secure code did)). Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 6 20:56:39 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16539 for ; Sat, 6 Sep 2003 20:56:38 -0400 (EDT) Received: (qmail 12482 invoked by uid 605); 7 Sep 2003 00:56:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12442 invoked from network); 7 Sep 2003 00:56:36 -0000 Received: from ozlabs.org (203.10.76.45) by mail.netbsd.org with SMTP; 7 Sep 2003 00:56:36 -0000 Received: by ozlabs.org (Postfix, from userid 1006) id 4A8052BC0A; Sun, 7 Sep 2003 10:56:31 +1000 (EST) Date: Sun, 7 Sep 2003 10:56:31 +1000 To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Sftp rename: 2 proposals Message-ID: <20030907005631.GB18328@ozlabs.org> References: <3F58C213.4090606@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F58C213.4090606@vandyke.com> User-Agent: Mutt/1.5.4i From: mbp@ozlabs.org (Martin Pool) Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Sep 05, 2003 at 11:04:19AM -0600, Joseph Galbraith wrote: > I made this proposal, but after not being able to find it, I realized > I screwed up sending it and it didn't ever make it to the list: > > All right, how about the following change: > > 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] > uint32 flags > > 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. I would be happy to see this proposal accepted rather than mine. I do think it is important the problem be addressed in some way. > flags is 0 or a combination of > > SSH_FXP_RENAME_OVERWRITE 0x00000001 > SSH_FXP_RENAME_ATOMIC 0x00000002 > SSH_FXP_RENAME_NATIVE 0x00000004 > SSH_FXP_RENAME_COPY_OK 0x00000008 > > If flags does not include SSH_FXP_RENAME_OVERWRITE, > and there already exists a file with the name > specified by newpath, the server MUST respond > with SSH_FX_FILE_ALREADY_EXISTS. > > If flags includes SSH_FXP_RENAME_ATOMIC, and > the destination file already exists, it is > replaced in an atomic fashion. I.e., there > is no observable instance in time where the > destination file does not exist. SSH_FXP_RENAME_ATOMIC > implies SSH_FXP_RENAME_OVERWRITE. s/instance/instant/? Perhaps rather than "does not exist" say something like "where the name does not refer to either the old or the new file", as the unix rename operation is described. Having a moment where the file appears empty or incomplete would be wrong, but this might happen for a copy/delete operation. Perhaps it should mention that "observable" includes other processes or SSH clients, not just this client. > There may, however, be some span of time where > both the source and destination file exist. > SSH_FXP_RENAME_ATOMIC has no bearing on the > source file. I'm not sure about this last sentence. If you just mean that both files may exist for a moment, it is redundant with the previous sentence. > If flags includes SSH_FXP_RENAME_ATOMIC and the > server cannot replace the destination in an > atomic fashion, then the server MUST respond > with SSH_FX_OP_UNSUPPORTED. > > Because some servers cannot provide atomic rename, > clients should only specify atomic rename if correct > operation requires it. If SSH_FXP_RENAME_OVERWRITE > is specified, the server MAY preform an atomic > rename even if it is not requested. > > If flags includes SSH_FXP_RENAME_NATIVE, the server > is free to do the rename operation in whatever > fashion it deems appropriate. Other flag values > are considered hints as to desired behavior, but > not requirements. > > If flags includes SSH_FXP_RENAME_COPY_OK, the > server MAY preform a copy / delete operation > in order to complete the operation. If an atomic > rename is also requested, the server may only > preform this sequence if it can do so in an > atomic fashion for the destination file. s/preform/perform/ I know what copy/delete is, but I don't understand the meaning or intention of this flag. Do you mean that e.g. cross-filesystem moves would be allowed only if this flag was specified, and they would fail otherwise? So presumably most clients would turn SSH_FXP_RENAME_COPY_OK on? Who would turn it off? Clients worried about the time it would take to copy the file? > The server may 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 message. [on my proposal] > o It is not possible to know if the server is unix (and I > think, in general, it is a bad idea to make decisions > based on OS type.) I wasn't suggesting that the client ought to send "are you unix?". However, if a human is using sftp interactively they *may* know what the remote filesystem is, and want to take advantage of that. > o If the client does _not_ wish to have the file replaced, > it must stat the file and wait for the response before > preceeding. That is a drawback. And there is a small race here as well: some other process might create a new file in the interim. > o As mentioned above, if the client wishes the file to > always be overwritten, it must delete the destination, > and then do the rename, but even that may _still_ fail > if something comes along and recreates the file in the > interim. (Imagine a system where the file must exist, > and so there is a monitor program which recreates the > file if it is deleted. Farfetched? Maybe. Possible? > Definitely.) But this problem also exists on server systems where the native rename does not overwrite. Rename-and-replace on Windows (I think) has to be implemented by deleting the file and then renaming. So there is still a race window, although since it does not include a network round trip it is smaller. > I think it is far better for the client to be able to specify > the behavior they want on the rename. Most clients are probably > happy with whatever the server does natively. Yes, I agree. I like that your proposal makes the "don't care" value obvious. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 7 22:21:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28301 for ; Sun, 7 Sep 2003 22:21:17 -0400 (EDT) Received: (qmail 8020 invoked by uid 605); 8 Sep 2003 02:21:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8013 invoked from network); 8 Sep 2003 02:21:12 -0000 Received: from sngrel5.hp.com (192.6.86.210) by mail.netbsd.org with SMTP; 8 Sep 2003 02:21:12 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel5.hp.com (Postfix) with SMTP id A8BA747E for ; Mon, 8 Sep 2003 10:21:08 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Sep 2003 12:21:07 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R6VQVB07; Mon, 8 Sep 2003 12:21:07 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Sep 2003 12:21:07 +1000 Received: from localhost ([127.0.0.1] helo=vexed) by vexed with smtp (Exim 3.36 #1 (Debian)) id 19wBe1-00055v-00 for ; Mon, 08 Sep 2003 12:20:45 +1000 Date: Mon, 8 Sep 2003 12:20:44 +1000 From: Martin Pool Cc: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers Message-Id: <20030908122044.5e9dafca.mbp@sourcefrog.net> In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > You raise a good point--- hmmm... let's try this on > for size: > > new attrib bit: > > SSH_FILEXFER_ATTR_FILESYSTEM > string filesystem-name > > SSH_FILEXFER_ATTR_FILESYSTEM is only sent by the server > if the client requested it by including in the flags > mask during readdir or stat operation and the file > in question is a directory. > > filesystem-name is a handle that can be passed back > to the server using the "read-filesystem-attributes" > It need not be human readable. Alternatively, you could make case sensitivity directly be an attribute of the directory, omitting a layer of indirection. (Of course this layer might be useful for discovering e.g. free space later.) > And, a new flag bit in in the modes during open to > specify that the filename should be case sensitive > or case insensitive. If the server can't comply, > it return OP_UNSUPPORTED. I take it this is intended to control only the way the server matches against existing filenames, and not to influence the way new files are created? So with case sensitivity on OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) in a directory containing "readme" ought to fail with FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and OPEN("README", READ|CASE_SENSITIVE) in a directory containing "readme" ought to fail with NO_SUCH_FILE even on a case-insensitive filesystem? Do you perhaps want a ternary for sensitive/insensitive/don't-care? Some clients might be happy to use whatever the server wants. If you give the client this option when opening files, then presumably it should have the option for all other operations that include filenames, including remove, rename, stat, etc. Since it affects many operations and clients are unlikely to want to change partway through, perhaps it should be a per-connection option? I would like to mention that in Samba and CIFS, experience has shown that negotiated case-sensitivity in a protocol was buggy and surprisingly hard to implement reliably efficiently. For example, many Windows applications use varying case for the same file even when NT tells them that they are not on a case-insensitive filesystem. Doing case-insensitive compares in Unicode is not trivial and there are implementations that get it wrong. Adding this bit doubles or triples the testing domain for many operations. I would suggest not adding this option unless you're really sure it's needed. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 7 22:42:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29303 for ; Sun, 7 Sep 2003 22:42:55 -0400 (EDT) Received: (qmail 20541 invoked by uid 605); 8 Sep 2003 02:42:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20534 invoked from network); 8 Sep 2003 02:42:57 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 8 Sep 2003 02:42:57 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01L0EA9JR43E8WW4ZH@RAPTOR.PSCCOS.COM> for ietf-ssh@NetBSD.org; Sun, 07 Sep 2003 20:42:54 -0700 (MST) Date: Sun, 07 Sep 2003 20:42:32 -0600 From: "Dan O'Reilly" Subject: Re: Case sensitivity on sftp servers In-reply-to: <20030908122044.5e9dafca.mbp@sourcefrog.net> X-Sender: oreilly@raptor.psccos.com To: Martin Pool Cc: ietf-ssh@NetBSD.org Message-id: <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list At 08:20 PM 9/7/2003, Martin Pool wrote: >So with case sensitivity on > > OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) > >in a directory containing "readme" ought to fail with >FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and > > OPEN("README", READ|CASE_SENSITIVE) > >in a directory containing "readme" ought to fail with NO_SUCH_FILE >even on a case-insensitive filesystem? No, it wouldn't necessarily do so on VMS, which supports multiple versions of files. Think outside the box, Grasshopper... >Adding this bit doubles or triples the testing domain for many >operations. I would suggest not adding this option unless you're >really sure it's needed. On UNIX, maybe not. On Windows, maybe not. But they're not the only systems... ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 00:35:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06814 for ; Mon, 8 Sep 2003 00:35:28 -0400 (EDT) Received: (qmail 28499 invoked by uid 605); 8 Sep 2003 04:35:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28486 invoked from network); 8 Sep 2003 04:35:25 -0000 Received: from sngrel5.hp.com (192.6.86.210) by mail.netbsd.org with SMTP; 8 Sep 2003 04:35:25 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel5.hp.com (Postfix) with SMTP id C24CE459 for ; Mon, 8 Sep 2003 12:35:23 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Sep 2003 14:35:17 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R6VQVGFV; Mon, 8 Sep 2003 14:35:16 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Sep 2003 14:35:16 +1000 Received: from localhost ([127.0.0.1] helo=vexed) by vexed with smtp (Exim 3.36 #1 (Debian)) id 19wDjp-0006Uq-00; Mon, 08 Sep 2003 14:34:53 +1000 Date: Mon, 8 Sep 2003 14:34:53 +1000 From: Martin Pool To: "Dan O'Reilly" Cc: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers Message-Id: <20030908143453.2395ba4c.mbp@sourcefrog.net> In-Reply-To: <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On 7 Sep 2003 Dan O'Reilly wrote: > At 08:20 PM 9/7/2003, Martin Pool wrote: > >So with case sensitivity on > > > > OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) > > > >in a directory containing "readme" ought to fail with > >FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and > > > > OPEN("README", READ|CASE_SENSITIVE) > > > >in a directory containing "readme" ought to fail with NO_SUCH_FILE > >even on a case-insensitive filesystem? > > No, it wouldn't necessarily do so on VMS, which supports multiple > versions of files. How would it behave on VMS, sensei? > Think outside the box, Grasshopper... -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 10:07:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21893 for ; Mon, 8 Sep 2003 10:07:28 -0400 (EDT) Received: (qmail 20016 invoked by uid 605); 8 Sep 2003 14:07:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20006 invoked from network); 8 Sep 2003 14:07:27 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 8 Sep 2003 14:07:27 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21821; Mon, 8 Sep 2003 10:07:16 -0400 (EDT) Message-Id: <200309081407.KAA21821@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-break-01.txt Date: Mon, 08 Sep 2003 10:07:16 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Session Channel Break Extension Author(s) : J. Galbraith, P. Remaker Filename : draft-ietf-secsh-break-01.txt Pages : 10 Date : 2003-9-8 The Break Extension provides a way to send a break signal during a SSH terminal session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-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-break-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-break-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: <2003-9-8083158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-break-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-break-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-8083158.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 10:17:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24150 for ; Mon, 8 Sep 2003 10:17:55 -0400 (EDT) Received: (qmail 26302 invoked by uid 605); 8 Sep 2003 14:17:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26294 invoked from network); 8 Sep 2003 14:17:58 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 8 Sep 2003 14:17:58 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01L0EYJ8P3XS8WW4ZH@RAPTOR.PSCCOS.COM> for ietf-ssh@NetBSD.org; Mon, 08 Sep 2003 08:17:55 -0700 (MST) Date: Mon, 08 Sep 2003 08:17:08 -0600 From: "Dan O'Reilly" Subject: Re: Case sensitivity on sftp servers In-reply-to: <20030908143453.2395ba4c.mbp@sourcefrog.net> X-Sender: oreilly@raptor.psccos.com To: Martin Pool Cc: ietf-ssh@NetBSD.org Message-id: <5.2.0.9.2.20030908081530.00b48890@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list At 10:34 PM 9/7/2003, Martin Pool wrote: >On 7 Sep 2003 Dan O'Reilly wrote: > > > At 08:20 PM 9/7/2003, Martin Pool wrote: > > >So with case sensitivity on > > > > > > OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) > > > > > >in a directory containing "readme" ought to fail with > > >FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and > > > > > > OPEN("README", READ|CASE_SENSITIVE) > > > > > >in a directory containing "readme" ought to fail with NO_SUCH_FILE > > >even on a case-insensitive filesystem? > > > > No, it wouldn't necessarily do so on VMS, which supports multiple > > versions of files. > >How would it behave on VMS, sensei? Well, specifically with respect to the example creating the file, it would simply create a new version of the file, leaving the old one intact (depending on if a version limit for the file/directory was set, and the depth to which it is set). ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 11:10:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29186 for ; Mon, 8 Sep 2003 11:10:42 -0400 (EDT) Received: (qmail 573 invoked by uid 605); 8 Sep 2003 15:10:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 566 invoked from network); 8 Sep 2003 15:10:45 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 8 Sep 2003 15:10:45 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h88FAiUH021790; Mon, 8 Sep 2003 09:10:44 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h88FAh6c027507; Mon, 8 Sep 2003 09:10:43 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h88F73Qx016249; Mon, 8 Sep 2003 08:07:03 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h88F73bM016248; Mon, 8 Sep 2003 08:07:03 -0700 (PDT) Date: Mon, 8 Sep 2003 08:07:03 -0700 From: Nicolas Williams To: ietf-krb-wg@anl.gov, ietf-ssh@NetBSD.org Subject: GSS-APIv2 Extension for Storing Delegated Credentials Message-ID: <20030908150702.GC11118@binky.central.sun.com> Mail-Followup-To: ietf-krb-wg@anl.gov, ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I just posted the following I-D, which I think the KRB WG and implementors of draft-ietf-secsh-gsskeyex may find interesting: http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt " Abstract This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. " Currently, any implementation of SSHv2 w/ gssapi userauth or keyex has to have some trouble dealing with delegated credentials, or the platform it runs on must make some annoying assumptions. For example, Simon Wilkinson's patches to OpenSSH require the use of interfaces that are internal to Heimdal, MIT krb5 or GSI in order to do anything useful with delegated credentials. The only ways, that I can see, to remove this use of internal interfaces are: - don't use delegated creds - have the GSS-API make the creds available only for the user account that is primariliy associated with the principal name of the delegated creds (but this means that the deleg creds won't be available when logging in to a different user account) - extend the GSS-API to correct the delegated credentials uselessness wrinkle This I-D proposes a simple extension to the GSS-API that allows acceptor applications to make delegated credentials available for acquisition and use to other processes sharing a given "credential store." [Note that the notion of "credential store" is implicit, as described in the I-D, in rfcs 2743 and 2744.] Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 16:20:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18570 for ; Mon, 8 Sep 2003 16:20:17 -0400 (EDT) Received: (qmail 3913 invoked by uid 605); 8 Sep 2003 20:20:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3906 invoked from network); 8 Sep 2003 20:20:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Sep 2003 20:20:19 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2187842; Mon, 08 Sep 2003 14:20:18 -0600 Message-ID: <3F5CE482.5070500@vandyke.com> Date: Mon, 08 Sep 2003 14:20:18 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Martin Pool CC: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> In-Reply-To: <20030908122044.5e9dafca.mbp@sourcefrog.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >>filesystem-name is a handle that can be passed back >>to the server using the "read-filesystem-attributes" >>It need not be human readable. > > > Alternatively, you could make case sensitivity directly be an > attribute of the directory, omitting a layer of indirection. (Of > course this layer might be useful for discovering e.g. free space > later.) Also, if the filesystem is different, the other characteristics of the filesystem may also change (reserved filenames and illegal characters. >>And, a new flag bit in in the modes during open to >>specify that the filename should be case sensitive >>or case insensitive. If the server can't comply, >>it return OP_UNSUPPORTED. > > I take it this is intended to control only the way the server matches > against existing filenames, and not to influence the way new files are > created? No. WinNT has the ability, at least under NTFS to optionally support case. I don't know about VMS? And maybe others. [...] > Do you perhaps want a ternary for sensitive/insensitive/don't-care? > Some clients might be happy to use whatever the server wants. This would be a good idea: CASE_NATIVE. > I would like to mention that in Samba and CIFS, experience has shown > that negotiated case-sensitivity in a protocol was buggy and > surprisingly hard to implement reliably efficiently. For example, > many Windows applications use varying case for the same file even when > NT tells them that they are not on a case-insensitive filesystem. > Doing case-insensitive compares in Unicode is not trivial and there > are implementations that get it wrong. > > Adding this bit doubles or triples the testing domain for many > operations. I would suggest not adding this option unless you're > really sure it's needed. I think I would tend to agree; while MS CreateFile() api does support this, many other APIs [such as DeleteFile()] don't. What I want is the ability to know whether or not Readme and README are the same file. And perhaps I don't really care about illegal characters and names. So, let me summerize our proposals: Case sensitivity proposal #1, alias: the-first-cut -------------------------------------------------- "default-fs-attribs@vandyke.com" -- o deal with only the system native case-sensitivity. o can't deal with multiple filesystem handling case differently. o can't deal with filesystems where case sensitivity is optional. Case sensitivity proposal #2, alias: the-whole-enchillada --------------------------------------------------------- "filesystem-name" + "read-filesystem-attributes" o deal with case sensitivity on a per directory bases, so multiple filesystems are handled. o Case sensitivity can be specified during open o Probably needs to specify sensitivity during delete/rename/etc.,etc. o Probably hard to implement and get reliable (based on Samba/CIFS experience.) Case sensitivity proposal #3, alias: the-lean-mean-case-sensitive-machine ------------------------------------------------------------------------- (And also deals with other issues on my list): New attrib bit: SSH_FILEXFER_ATTR_FLAGS The 'flags' field is any combination of the following bits: SSH_FILEXFER_ATTR_FLAGS_READONLY Advisory readonly bit. This bit is not part of the access control information on the file, but is rather an advisory field indicating that the file should not be written. For example, some source code control systems use this bit to indicate that the file is not locked, and therefor should not be modified. When the file is locked, the bit is cleared. SSH_FILEXFER_ATTR_FLAGS_SYSTEM The file is part of operating system. SSH_FILEXFER_ATTR_FLAGS_HIDDEN File should not be shown to user unless specifically requested. For example, most unix systems should set this bit if the filename begins with a 'period'. SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE (directory only) Files & directory names in this directory should be compared with-out regard to case. It is recommended that where possible, the filesystem be allowed to do comparisons. For example, if a client wished to prompt a user before overwriting a file, it should not compare the new name with the previously retrieved list of names in the directory. Rather, it should first try to create the new file by specifying SSH_FXF_CREAT without the SSH_FXF_TRUNC flag. Then, if this fails and returns SSH_FX_FILE_ALREADY_EXISTS, it should prompt the user and then retry the create specifying SSH_FXF_TRUNC. The case insensitive flag should only be used to implement name globbing or other filename based filtering systems. Unless otherwise specified, filenames are assumed to be case sensitive. SSH_FILEXFER_ATTR_FLAGS_ARCHIVE The file should be included in backup / archive operations. SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED The file should be encrypted. If the filesystem doesn't support encryption, the operation must return UNSUPPORTED. SSH_FILEXFER_ATTR_FLAGS_COMPRESSED The file should be compressed. If the filesystem doesn't support compression, the operation must return UNSUPPORTED. SSH_FILEXFER_ATTR_FLAGS_SPARSE_OPTION SSH_FILEXFER_ATTR_FLAGS_SPARSE_REQUIRED The file should be sparse. If SPARSE_REQUIRED is specified, the operation MUST fail if it is not supported. My preference at this point leans toward #3. Do any other implementors supporting other operating systems have bits that would be appropriate for this field? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 19:37:51 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28643 for ; Mon, 8 Sep 2003 19:37:50 -0400 (EDT) Received: (qmail 4428 invoked by uid 605); 8 Sep 2003 23:37:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4421 invoked from network); 8 Sep 2003 23:37:48 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Sep 2003 23:37:48 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2189685 for ietf-ssh@NetBSD.org; Mon, 08 Sep 2003 17:37:46 -0600 Message-ID: <3F5D12CA.7030908@vandyke.com> Date: Mon, 08 Sep 2003 17:37:46 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: "'ietf-ssh@netbsd.org'" Subject: A proposal for OPEN X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit As we've worked with SFTP v4, we've found the open command a little awkward in some cases because the client can't really specify what access it wants and so we are left guessing how to open the file. For example, we typically open the file with READ_DATA and/or WRITE_DATA access, but not with WRITE_ACL. If the client does a fsetstat and includes an ACL, we will fail because we didn't open the file with enough access. But, if we opened the file for WRITE_ACL, we might fail to open the file and the client never would have attempted to write an acl anyway. I'm proposing the following new open command for v5: byte SSH_FXP_OPEN string filename uint32 access_desired uint32 access_flags attrib open_attrs access_desired Any of the ace-mask flags from section 5.7. access_flags The access_flags is two seperate bit fields. Bit values in the 0xFFFF0000 mask are required, and if they can not be supported, the operation MUST fail. Bit values in the 0x0000FFFF mask are requested, but if they can not be supported the operation SHOULD continue. Clients MUST NOT send any undefined bits in the access_flags field. Servers should ignore any bits not specified here. Future IETF action may add additional bits without reving the version number. The following required fields are defined: ACCESS_DISPOSITION = 0x00070000 CREATE_NEW = 0x00000000 CREATE_OVERWRITE = 0x00010000 OPEN_EXISTING = 0x00020000 OPEN_OR_CREATE = 0x00030000 TRUNCATE_EXISTING = 0x00040000 ACCESS_APPEND_DATA = 0x00080000 The following required fields are defined: ACCESS_SHARE_READ = 0x00000001 ACCESS_SHARE_WRITE = 0x00000002 ACCESS_SHARE_DELETE = 0x00000004 Several flags in the SSH_FILEXFER_ATTR_FLAGS in the open_attrs also control aspects of file creation; this flags have no affect during file open (to change these values for existing files, clients MUST use setstat or fsetstat) SSH_FILEXFER_ATTR_FLAGS_READONLY Advisory readonly bit should be set. (This does not affect the current operation, only future operation.) SSH_FILEXFER_ATTR_FLAGS_SYSTEM The file should be marked as part of operating system. SSH_FILEXFER_ATTR_FLAGS_HIDDEN File should be hidden from the user. SSH_FILEXFER_ATTR_FLAGS_ARCHIVE The file should be included in backup / archive operations. SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED The file should be encrypted. If the filesystem doesn't support encryption, the operation must return UNSUPPORTED. SSH_FILEXFER_ATTR_FLAGS_COMPRESSED The file should be compressed. If the filesystem doesn't support compression, the operation must return UNSUPPORTED. SSH_FILEXFER_ATTR_FLAGS_SPARSE_OPTION SSH_FILEXFER_ATTR_FLAGS_SPARSE_REQUIRED The file should be sparse. If SPARSE_REQUIRED is specified, the operation MUST fail if it is not supported. ----- I've chosen the DISPOSITION value over the previous CREAT/TRUNC/EXCL bit mask because it: a. takes the same three bits b. removes the ability to specify poorly defined combinations (TRUNC|EXCL) c. I think it is easier to understand. d. Has room for expanision if we need it What do people think? Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 20:46:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00241 for ; Mon, 8 Sep 2003 20:46:03 -0400 (EDT) Received: (qmail 23514 invoked by uid 605); 9 Sep 2003 00:46:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23503 invoked from network); 9 Sep 2003 00:46:01 -0000 Received: from sngrel7.hp.com (192.6.86.111) by mail.netbsd.org with SMTP; 9 Sep 2003 00:46:01 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel7.hp.com (Postfix) with SMTP id 98FEC2F4 for ; Tue, 9 Sep 2003 08:45:58 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 09 Sep 2003 10:45:57 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R6VQVXQJ; Tue, 9 Sep 2003 10:45:57 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 09 Sep 2003 10:45:57 +1000 Received: from localhost ([127.0.0.1] helo=vexed) by vexed with smtp (Exim 3.36 #1 (Debian)) id 19wWdQ-0005KC-00 for ; Tue, 09 Sep 2003 10:45:32 +1000 Date: Tue, 9 Sep 2003 10:45:32 +1000 From: Martin Pool To: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers Message-Id: <20030909104532.2974b930.mbp@sourcefrog.net> In-Reply-To: <5.2.0.9.2.20030908081530.00b48890@raptor.psccos.com> References: <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <5.2.0.9.2.20030907203950.00b49d18@raptor.psccos.com> <5.2.0.9.2.20030908081530.00b48890@raptor.psccos.com> X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On 8 Sep 2003 Dan O'Reilly wrote: > At 10:34 PM 9/7/2003, Martin Pool wrote: > >On 7 Sep 2003 Dan O'Reilly wrote: > > > > > At 08:20 PM 9/7/2003, Martin Pool wrote: > > > >So with case sensitivity on > > > > > > > > OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) > > > > > > > >in a directory containing "readme" ought to fail with > > > >FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and > > > > > > > > OPEN("README", READ|CASE_SENSITIVE) > > > > > > > >in a directory containing "readme" ought to fail with > > > >NO_SUCH_FILE even on a case-insensitive filesystem? > > > > > > No, it wouldn't necessarily do so on VMS, which supports multiple > > > versions of files. > > > >How would it behave on VMS, sensei? > > Well, specifically with respect to the example creating the file, it > would simply create a new version of the file, leaving the old one > intact(depending on if a version limit for the file/directory was set, > and the depth to which it is set). Doesn't that contradict the meaning of SSH_FXF_EXCL? Causes the request to fail if the named file already exists. Anyhow, what does that have to do with case sensitivity? -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 21:28:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01024 for ; Mon, 8 Sep 2003 21:28:12 -0400 (EDT) Received: (qmail 21710 invoked by uid 605); 9 Sep 2003 01:28:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21703 invoked from network); 9 Sep 2003 01:28:15 -0000 Received: from sngrel7.hp.com (192.6.86.111) by mail.netbsd.org with SMTP; 9 Sep 2003 01:28:15 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel7.hp.com (Postfix) with SMTP id 59FFD764 for ; Tue, 9 Sep 2003 09:28:13 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 09 Sep 2003 11:28:12 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R6VQVZC7; Tue, 9 Sep 2003 11:28:12 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 09 Sep 2003 11:28:11 +1000 Received: from localhost ([127.0.0.1] helo=vexed) by vexed with smtp (Exim 3.36 #1 (Debian)) id 19wXII-0005NX-00 for ; Tue, 09 Sep 2003 11:27:46 +1000 Date: Tue, 9 Sep 2003 11:27:46 +1000 From: Martin Pool To: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers Message-Id: <20030909112746.250062e9.mbp@sourcefrog.net> In-Reply-To: <3F5CE482.5070500@vandyke.com> References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> <3F5CE482.5070500@vandyke.com> X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On 8 Sep 2003 Joseph Galbraith wrote: > >>And, a new flag bit in in the modes during open to > >>specify that the filename should be case sensitive > >>or case insensitive. If the server can't comply, > >>it return OP_UNSUPPORTED. > > > > I take it this is intended to control only the way the server > > matches against existing filenames, and not to influence the way new > > files are created? > > No. WinNT has the ability, at least under NTFS to > optionally support case. Yes, the filesystem supports it, but as far as I know it cannot usefully be accessed from applications except from in the crippled POSIX mode. See e.g. http://techsupt.winbatch.com/TS/T000001036004F26.html In any case this is a per-filesystem option, not something that can be specified when creating a file. It's hard to imagine a filesystem where you can specify that when you create a file, though perhaps it could be supported when creating a directory. > I don't know about VMS? And maybe others. I think VMS is always case-insensitive. OS X is an interesting case because it commonly uses both case-sensitive (UFS) and case-preserving (HFS) filesystems. However in neither case does the application get to choose which semantics it wants. All you can do is find out what a particular directory/filesystem will do. (Linux is similar, although the case-insensitive filesystems are less often used.) > > Do you perhaps want a ternary for sensitive/insensitive/don't-care? > > Some clients might be happy to use whatever the server wants. > > This would be a good idea: CASE_NATIVE. > > > I would like to mention that in Samba and CIFS, experience has shown > > that negotiated case-sensitivity in a protocol was buggy and > > surprisingly hard to implement reliably efficiently. For example, > > many Windows applications use varying case for the same file even > > when NT tells them that they are not on a case-insensitive > > filesystem. Doing case-insensitive compares in Unicode is not > > trivial and there are implementations that get it wrong. > > > > Adding this bit doubles or triples the testing domain for many > > operations. I would suggest not adding this option unless you're > > really sure it's needed. > > I think I would tend to agree; while MS CreateFile() api does support > this, many other APIs [such as DeleteFile()] don't. Yes, creating files that you can't rename or delete is not very useful. > What I want is the ability to know whether or not Readme > and README are the same file. > And perhaps I don't really care about illegal characters and names. Perhaps it's easier to have clients just try it and see? That's simpler, more reliable and probably not too expensive. > New attrib bit: SSH_FILEXFER_ATTR_FLAGS > > The 'flags' field is any combination of the following bits: > SSH_FILEXFER_ATTR_FLAGS_READONLY > Advisory readonly bit. This bit is not part of the > access control information on the file, but is rather > an advisory field indicating that the file should not > be written. > > For example, some source code control systems use this > bit to indicate that the file is not locked, and therefor > should not be modified. When the file is locked, the bit > is cleared. > > SSH_FILEXFER_ATTR_FLAGS_SYSTEM > The file is part of operating system. > > SSH_FILEXFER_ATTR_FLAGS_HIDDEN > File should not be shown to user unless specifically > requested. For example, most unix systems should set > this bit if the filename begins with a 'period'. On Unix this would presumably be a readonly bit? > SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE (directory only) > Files & directory names in this directory should be compared > with-out regard to case. > > It is recommended that where possible, the filesystem be > allowed to do comparisons. For example, if a client wished > to prompt a user before overwriting a file, it should not > compare the new name with the previously retrieved list of > names in the directory. Rather, it should first try to > create the new file by specifying SSH_FXF_CREAT without the > SSH_FXF_TRUNC flag. I like this recommendation, but should it use SSH_FXF_EXCL as well? > Then, if this fails and returns > SSH_FX_FILE_ALREADY_EXISTS, it should prompt the user and > then retry the create specifying SSH_FXF_TRUNC. > > The case insensitive flag should only be used to implement > name globbing or other filename based filtering systems. > > Unless otherwise specified, filenames are assumed to be case > sensitive. > > SSH_FILEXFER_ATTR_FLAGS_ARCHIVE > The file should be included in backup / archive operations. > > SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED > The file should be encrypted. If the filesystem doesn't > support encryption, the operation must return UNSUPPORTED. > > SSH_FILEXFER_ATTR_FLAGS_COMPRESSED > The file should be compressed. If the filesystem doesn't > support compression, the operation must return UNSUPPORTED. > > SSH_FILEXFER_ATTR_FLAGS_SPARSE_OPTION > SSH_FILEXFER_ATTR_FLAGS_SPARSE_REQUIRED > The file should be sparse. If SPARSE_REQUIRED is specified, > the operation MUST fail if it is not supported. > > My preference at this point leans toward #3. Do any other > implementors supporting other operating systems have bits that would > be appropriate for this field? #3 looks good to me too. Does putting all these bits in a single attribute cause a problem when setting the attributes? Some clients might not have permission to set some bits; or the bits might be readonly. I suppose the server has to just ignore those bits if they already have the specified values. If you are collecting a list of bits, you might like to include some Linux attribute bits, some of which are on other systems too. I don't think they're a priority for remote access, but access over filexfer be useful for backups: SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY The file can only be opened for writing in append mode. SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE The file cannot be deleted or renamed, no hard link can be created to this file and no data can be written to the file. This bit implies a stronger level of protection than SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or ACLs. Typically even the superuser cannot write to immutable files, and only the superuser can set or remove the bit. SSH_FILEXFER_ATTR_FLAGS_SYNC When the file is modified, the changes are written synchronously to the disk. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 8 23:44:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04568 for ; Mon, 8 Sep 2003 23:43:55 -0400 (EDT) Received: (qmail 18117 invoked by uid 605); 9 Sep 2003 03:41:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18110 invoked from network); 9 Sep 2003 03:41:46 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 9 Sep 2003 03:41:46 -0000 Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa28454; 8 Sep 2003 23:41 EDT Date: Mon, 08 Sep 2003 23:41:36 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , "'ietf-ssh@netbsd.org'" Subject: Re: A proposal for OPEN Message-ID: <751432704.1063078896@mariner.pc.cs.cmu.edu> In-Reply-To: <3F5D12CA.7030908@vandyke.com> References: <3F5D12CA.7030908@vandyke.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, September 08, 2003 17:37:46 -0600 Joseph Galbraith wrote: > byte SSH_FXP_OPEN > string filename > uint32 access_desired > uint32 access_flags > attrib open_attrs > > access_flags > The access_flags is two seperate bit fields. Bit values > in the 0xFFFF0000 mask are required, and if they can not > be supported, the operation MUST fail. > > Bit values in the 0x0000FFFF mask are requested, but if they > can not be supported the operation SHOULD continue. > > Clients MUST NOT send any undefined bits in the access_flags > field. Servers should ignore any bits not specified here. > > Future IETF action may add additional bits without > reving the version number. This isn't really self-consistent. Are bits in the 0xffff0000 group critical or not? Given that new bits can be defined without bumping the version number, it's important that the behaviour of a server depend on whether the server supports a given flag, and not whether the server was implemented before or after a given flag was defined. Given that you've indicated you want to be able to add flags without bumping the version, and that you've gone out of your way to indicate which potential future flags would be critical and which would not, I'd say you do want servers to reject critical flags of which they're unaware. I'd suggest something like this: The access_flags is two separate bit fields. Bit values in the 0xffff0000 mask are required, while bit values in the 0x000ffff mask are requested. Clients must not send any undefined bits in the access_flags field. Bit values in the 0xffff0000 mask are required; if a flag in this range is set and cannot be supported by the server, the operation MUST fail. Bit values in the 0x0000ffff mask are requested; if a flag in this range is set and its meaning is not known to the server, the operation MUST continue as if the flag had not been set. If such a flag is set and its meaning is known to the server, but cannot be supported, the server MAY report an appropriate error or allow the operation to continue as if the flag had not been set. Future IETF action may add additional bits without any need to change the protocol version number. [ I think something slightly stronger is warranted -- the available space is small, and should probably only be used for "mainstream" revisions of the protocol and not private extensions. ] > The following required fields are defined: > ACCESS_DISPOSITION = 0x00070000 > CREATE_NEW = 0x00000000 > CREATE_OVERWRITE = 0x00010000 > OPEN_EXISTING = 0x00020000 > OPEN_OR_CREATE = 0x00030000 > TRUNCATE_EXISTING = 0x00040000 > ACCESS_APPEND_DATA = 0x00080000 The meanings of these are more or less obvious, but they should be spelled out, I think. In terms of traditional UNIX open flags, I think these mean: CREATE_NEW = O_CREAT | O_EXCL CREATE_OVERWRITE = O_CREAT | O_TRUNC OPEN_EXISTING = 0 OPEN_OR_CREATE = O_CREAT TRUNCATE_EXISTING = O_TRUNC ACCESS_APPEND_DATA = O_APPEND Is this correct? Note that the semantics of ACCESS_APPEND_DATA are not entirely clear, especially when used with CREATE_NEW, CREATE_OVERWRITE, or TRUNCATE_EXISTNG. Does this merely indicate that the file position pointer is positioned to the EOF when the file is opened, or does it mean that every write is performed atomically at the EOF, without changing the file position pointer and without any chance of conflict with another appending process? If the former, then the flag has no effect in cases where the file will have 0 length after the open, and we shoulld drop it entirely and instead defined dispositions APPEND_EXISTING and APPEND_OR_CREATE. If the latter, this needs to be spelled out, and it should be clear that if a server cannot actually support the atomic-append behaviour, it MUST fail the operation. Of course, that leaves you with no means of getting a non-atomic append if that is sufficient. > The following required fields are defined: > ACCESS_SHARE_READ = 0x00000001 > ACCESS_SHARE_WRITE = 0x00000002 > ACCESS_SHARE_DELETE = 0x00000004 The meanings of these are not obvious to me, probably because they're drawn from some Windows terminology with which I'm not familiar. > I've chosen the DISPOSITION value over the previous > CREAT/TRUNC/EXCL bit mask because it: > > a. takes the same three bits > b. removes the ability to specify poorly defined > combinations (TRUNC|EXCL) > c. I think it is easier to understand. > d. Has room for expanision if we need it Yes; this sounds quite reasonable. The interactions of O_CREAT, O_EXCL, and O_TRUNC will be familiar to UNIX folk, but not to others, and the combination of TRUNC and EXCL is indeed ill-defined. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 07:11:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00725 for ; Tue, 9 Sep 2003 07:11:13 -0400 (EDT) Received: (qmail 4591 invoked by uid 605); 9 Sep 2003 11:11:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4584 invoked from network); 9 Sep 2003 11:11:07 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 9 Sep 2003 11:11:07 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h89BB1Zs032211; Tue, 9 Sep 2003 23:11:01 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h89BC9L25085; Tue, 9 Sep 2003 23:12:09 +1200 Date: Tue, 9 Sep 2003 23:12:09 +1200 Message-Id: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@east.sun.com Subject: Re: Sftp: performance enhancing changes Cc: galb@vandyke.com, ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >>>o Ignoring channel window makes for a screaming >>> sftp transfer. (unacceptable, breaks multiplexing.) >> >>It's only unacceptable if you're actually doing multiplexing. If you're just >>using SFTP as a secure FTP replacement (which is what many people seem to be >>using it for), it's a simple, quick fix for the SFTP performance problems. > >My understanding based on reading the earlier discussion is that this is a >red herring -- the fix (which doesn't involve violating the specs) is to >pipeline read/write requests and ensure the channel window is substantially >larger than the TCP window). Two comments on this.. 1. It doesn't involve violating the spec. You just advertise a maximum-size window (for the SSH level) and read a file as a single large chunk rather than lots of little bits and pieces (at the SFTP level). Neither violate the spec. 2. Pipelining reads/writes and whatnot is a nice theoretical fix, but the fact that this problem has been around for what, five years now without anyone fixing it, and is enough of a problem that it comes up again and again in newsgroups, mailing lists, etc etc, indicates that just because a theoretical fix exists doesn't mean that implementations are able or willing to make use of it (heck, Tanenbaum's 1981 edition of Computer Networks covered this problem, and yet it's still present in stuff released this year, which indicates that it's not going to go away any time soon). Let me provide a concrete example of where this sort of thing leads... the motivation for me originally doing the handbrake writeup was a conversation with someone at a large US financial institution who were using SFTP to transfer some sort of large money-related files around (batch EDI transactions I assume). They were doing this over fixed-bandwidth, very expensive leased lines (slow, high-latency, the perfect environment for the handbrake to take effect), and found that they were getting only a fraction of the expected throughput. Their options were to either pay for more expensive leased lines, or (as they eventually found via trial and error) switch to SSL. In the end they dumped SSH and switched to SSL instead, which, even though it does exactly the same thing as SSH, ran at the full link speed. I offered to do them a handbrake-free STFP on top of my handbrake-free SSH code, but by then they had committed to SSL. So although it's possible to say "We have a theoretical fix which, if correctly applied by both sides and under ideal conditions, should work OK", the fact that anything except carefully-optimised, tuned SSH implementations provide poor throughput isn't really helping anyone except the SSL vendors, whose implementations don't have this problem. Since there are a large number of SSH implementations out there (surprisingly so, it's turning up as an add- on to all sorts of Windows apps that do file/data transfer, which is nice to see), more and more stuff is being SSH-enabled by people who don't know about the handbrake and don't know or care about spending a lot of time doing the necessary tuning to get adequate performance. The situation is just going to get worse... Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 10:52:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14594 for ; Tue, 9 Sep 2003 10:52:50 -0400 (EDT) Received: (qmail 9520 invoked by uid 605); 9 Sep 2003 14:52:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9513 invoked from network); 9 Sep 2003 14:52:50 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 9 Sep 2003 14:52:50 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Sep 2003 10:52:49 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC219@lespaul.process.com> From: Richard Whalen To: "'Martin Pool'" , ietf-ssh@NetBSD.org Subject: RE: Case sensitivity on sftp servers Date: Tue, 9 Sep 2003 10:52:47 -0400 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 >From: Martin Pool [mailto:mbp@sourcefrog.net] >Sent: Monday, September 08, 2003 9:28 PM >To: ietf-ssh@NetBSD.org >Subject: Re: Case sensitivity on sftp servers >On 8 Sep 2003 Joseph Galbraith wrote: >> I don't know about VMS? And maybe others. >I think VMS is always case-insensitive. VMS ODS-2 file systems are case-insensitive. VMS ODS-5 file systems (Alpha processors only) are case-preservative. If the version of VMS (Alpha processor) is 7.3-1 (or greater) and the file system is ODS-5, then the process (user) can opt for file opens to be case sensitive. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 10:53:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14635 for ; Tue, 9 Sep 2003 10:53:22 -0400 (EDT) Received: (qmail 9891 invoked by uid 605); 9 Sep 2003 14:53:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9848 invoked from network); 9 Sep 2003 14:53:00 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Sep 2003 14:53:00 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2193396; Tue, 09 Sep 2003 08:52:59 -0600 Message-ID: <3F5DE94B.2070103@vandyke.com> Date: Tue, 09 Sep 2003 08:52:59 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: sommerfeld@east.sun.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes References: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> In-Reply-To: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Bill Sommerfeld writes: > >>>>o Ignoring channel window makes for a screaming >>>> sftp transfer. (unacceptable, breaks multiplexing.) >>> >>>It's only unacceptable if you're actually doing multiplexing. If you're just >>>using SFTP as a secure FTP replacement (which is what many people seem to be >>>using it for), it's a simple, quick fix for the SFTP performance problems. >> >>My understanding based on reading the earlier discussion is that this is a >>red herring -- the fix (which doesn't involve violating the specs) is to >>pipeline read/write requests and ensure the channel window is substantially >>larger than the TCP window). > > > Two comments on this.. > > 1. It doesn't involve violating the spec. You just advertise a maximum-size > window (for the SSH level) and read a file as a single large chunk rather > than lots of little bits and pieces (at the SFTP level). Neither violate > the spec. Well, perhaps I misunderstood what you were proposing then. Ignoring the channel window during data send is certainly a protocol violation. However, if the remote side has given the client a huge window (something the client has no control over), the client is certainly free to use it. And more: it should use it. The limit on the size of a single SFTP read exists for good reason (as discussed previously.) I don't think we can remove it. There are two different solutions, however, if you want to achieve the same result: 1. Issue multiple reads, for some reasonable amount of data. Feel free to issue all the reads needed to fetch the entire file at once, if you want to. This requires no change in the protocol, and can be done with any previously documented version of the protocol. 2. Add support for multi-response reads to the protocol. I.e., allow the server to respond to your gaint read request with multiple smaller sftp data packets. That way the server doesn't have to commit to sending you a 40 gig sftp data packet only to have the last 39gig dissappear before it can send it, and be forced to send you 39 gig of zeros before it can tell you that an error occured. > 2. Pipelining reads/writes and whatnot is a nice theoretical fix, but the fact > that this problem has been around for what, five years now without anyone > fixing it Well, unless I'm mistaken, Markus said that OpenSSH had fixed it and was now seeing throughput roughly equivilant to SCP. The next version of VanDyke's software will also contain optimizations of this nature. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 10:53:51 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14704 for ; Tue, 9 Sep 2003 10:53:51 -0400 (EDT) Received: (qmail 11324 invoked by uid 605); 9 Sep 2003 14:53:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11312 invoked from network); 9 Sep 2003 14:53:49 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Sep 2003 14:53:49 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2193389; Tue, 09 Sep 2003 08:53:49 -0600 Message-ID: <3F5DE97C.2020908@vandyke.com> Date: Tue, 09 Sep 2003 08:53:48 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Martin Pool CC: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> <3F5CE482.5070500@vandyke.com> <20030909112746.250062e9.mbp@sourcefrog.net> In-Reply-To: <20030909112746.250062e9.mbp@sourcefrog.net> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Martin Pool wrote: >>>I take it this is intended to control only the way the server >>>matches against existing filenames, and not to influence the way new >>>files are created? >> >>No. WinNT has the ability, at least under NTFS to >>optionally support case. > > Yes, the filesystem supports it, but as far as I know it cannot > usefully be accessed from applications except from in the crippled > POSIX mode. See e.g. > > http://techsupt.winbatch.com/TS/T000001036004F26.html > > In any case this is a per-filesystem option, not something that can be > specified when creating a file. Actually, the Win32 CreateFile() api takes a flag: FILE_FLAG_POSIX_SEMANTICS Indicates that the file is to be accessed according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support such naming. Use care when using this option because files created with this flag may not be accessible by applications written for MS-DOS or 16-bit Windows. So it is accessable from Win32 (not just from the posix subsystem) and can be specified when creating the file. I'm not sure when this flag was introduced; it may have been with windows 2000. > It's hard to imagine a filesystem where you can specify that when you > create a file, though perhaps it could be supported when creating a > directory. Unfortunately, I don't think Win32 offers support for creating case-sensitive directories. Or for any other case-sensitive operations. Though if you are willing to go straight to the NT API (as opposed to the Win32 API) I'm quite sure that you can do any file operation you want in either a case sensitive fashion or case insensitive. (Provided of course, you are working with an NTFS partition or some other filesystem that can support both.) > [...] >> SSH_FILEXFER_ATTR_FLAGS_HIDDEN >> File should not be shown to user unless specifically >> requested. For example, most unix systems should set >> this bit if the filename begins with a 'period'. > > On Unix this would presumably be a readonly bit? Yes, I would think so. >> SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE (directory only) >> Files & directory names in this directory should be compared >> with-out regard to case. >> >> It is recommended that where possible, the filesystem be >> allowed to do comparisons. For example, if a client wished >> to prompt a user before overwriting a file, it should not >> compare the new name with the previously retrieved list of >> names in the directory. Rather, it should first try to >> create the new file by specifying SSH_FXF_CREAT without the >> SSH_FXF_TRUNC flag. > > > I like this recommendation, but should it use SSH_FXF_EXCL as well? Yes, you are correct. >>My preference at this point leans toward #3. Do any other >>implementors supporting other operating systems have bits that would >>be appropriate for this field? > > > #3 looks good to me too. > > Does putting all these bits in a single attribute cause a problem when > setting the attributes? Some clients might not have permission to set > some bits; or the bits might be readonly. I suppose the server has to > just ignore those bits if they already have the specified values. Well, it means you probably have to read the mask before you write it (like mode bits if you only want to change the other permissions.) > If you are collecting a list of bits, you might like to include some > Linux attribute bits, some of which are on other systems too. I don't > think they're a priority for remote access, but access over filexfer > be useful for backups: > > SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY > > The file can only be opened for writing in append mode. > > SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE > > The file cannot be deleted or renamed, no hard link can be > created to this file and no data can be written to the file. > > This bit implies a stronger level of protection than > SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or > ACLs. Typically even the superuser cannot write to immutable > files, and only the superuser can set or remove the bit. > > SSH_FILEXFER_ATTR_FLAGS_SYNC > > When the file is modified, the changes are written > synchronously to the disk. Excellent; I'll add these-- being able to do good backups is one of the applications that has been on my mind. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 11:28:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17450 for ; Tue, 9 Sep 2003 11:28:54 -0400 (EDT) Received: (qmail 2531 invoked by uid 605); 9 Sep 2003 15:28:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2524 invoked from network); 9 Sep 2003 15:28:57 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Sep 2003 15:28:57 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2193539; Tue, 09 Sep 2003 09:28:56 -0600 Message-ID: <3F5DF1B8.8010303@vandyke.com> Date: Tue, 09 Sep 2003 09:28:56 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: "'ietf-ssh@netbsd.org'" Subject: Re: A proposal for OPEN References: <3F5D12CA.7030908@vandyke.com> <751432704.1063078896@mariner.pc.cs.cmu.edu> In-Reply-To: <751432704.1063078896@mariner.pc.cs.cmu.edu> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >> access_flags >> The access_flags is two seperate bit fields. Bit values >> in the 0xFFFF0000 mask are required, and if they can not >> be supported, the operation MUST fail. >> >> Bit values in the 0x0000FFFF mask are requested, but if they >> can not be supported the operation SHOULD continue. >> >> Clients MUST NOT send any undefined bits in the access_flags >> field. Servers should ignore any bits not specified here. >> >> Future IETF action may add additional bits without >> reving the version number. > > > This isn't really self-consistent. Arghh... of course, you are right. I failed to go back and rework that section. > I'd suggest something like this: > > The access_flags is two separate bit fields. Bit values in the > 0xffff0000 mask are required, while bit values in the 0x000ffff mask are > requested. Clients must not send any undefined bits in the access_flags > field. > > Bit values in the 0xffff0000 mask are required; if a flag in this range > is set and cannot be supported by the server, the operation MUST fail. > > Bit values in the 0x0000ffff mask are requested; if a flag in this range > is set and its meaning is not known to the server, the operation MUST > continue as if the flag had not been set. If such a flag is set and its > meaning is known to the server, but cannot be supported, the server MAY > report an appropriate error or allow the operation to continue as if the > flag had not been set. > > Future IETF action may add additional bits without any need to change > the protocol version number. Excellent. > [ I think something slightly stronger is warranted -- the available > space is small, and should probably only be used for "mainstream" > revisions of the protocol and not private extensions. ] Yes, this sounds reasonable. >> The following required fields are defined: >> ACCESS_DISPOSITION = 0x00070000 >> CREATE_NEW = 0x00000000 >> CREATE_OVERWRITE = 0x00010000 >> OPEN_EXISTING = 0x00020000 >> OPEN_OR_CREATE = 0x00030000 >> TRUNCATE_EXISTING = 0x00040000 >> ACCESS_APPEND_DATA = 0x00080000 > > > The meanings of these are more or less obvious, but they should be > spelled out, I think. In terms of traditional UNIX open flags, I think > these mean: > > CREATE_NEW = O_CREAT | O_EXCL > CREATE_OVERWRITE = O_CREAT | O_TRUNC > OPEN_EXISTING = 0 > OPEN_OR_CREATE = O_CREAT > TRUNCATE_EXISTING = O_TRUNC > > ACCESS_APPEND_DATA = O_APPEND > > Is this correct? Yes. I'll spell it out in the draft. > Note that the semantics of ACCESS_APPEND_DATA are not entirely clear > [...] You raise a good point. How about: ACCESS_APPEND_DATA_ATOMIC = 0x00080000 ACCESS_APPEND_DATA = 0x00100000 ACCESS_APPEND_DATA_ATOMIC ACCESS_APPEND_DATA Data is always written at the end of the file. The offset field of the SSH_FXP_WRITE requests are ignored. If the ATOMIC flag is used, then data must be written atomically to the end of the file without any chance of conflict with another appender. If the APPEND_DATA flag is used, atomic append is not required, but the server MAY still use atomic appends if it so chooses. Clients should balance the possibility that a server may not support atomic appends against the possibility of other writers conflicting. If the file is not opened with SHARE_WRITE, there is no need for atomic appends. >> The following required fields are defined: >> ACCESS_SHARE_READ = 0x00000001 >> ACCESS_SHARE_WRITE = 0x00000002 >> ACCESS_SHARE_DELETE = 0x00000004 > > > The meanings of these are not obvious to me, probably because they're > drawn from some Windows terminology with which I'm not familiar. ACCESS_SHARE_READ This flag indicates that client is willing to allow other readers of the file to simultaneously co-exist. ACCESS_SHARE_WRITE This flag indicates that client is willing to allow other writers of the file to simultaneously co-exist. ACCESS_SHARE_DELETE This flag indicates that client is willing to allow the file to be deleted while it is accessing it. For example, to display a log file that is being updated by a daemon process, the client would open the file for READ_DATA access, and specify that it was will to allow other writers (the daemon process) by specifying ACCESS_SHARE_WRITE. Previous versions of the protocol did not support these options, and so the behavior was implementation dependant. Clients that do not care about this, or wish to continue to leave the decision up to the server should specify all three sharing bits. If the client requests an exclusive access (does not set one of the share bits), but the server can not provide the such locking, it SHOULD fail the request. However, if the client is willing to share access, but the server does not support this kind of sharing, it SHOULD allow the request to succeed anyway. Another alternative would be to reverse the fields (I'm familiar with the windows varient, but remember a time when I found them frustrating.) Would people find the following easier to parse: ACCESS_READ_LOCK ACCESS_WRITE_LOCK ACCESS_DELETE_LOCK The client wishes to be the lock out other reader, writers, writers or deleters. For example, the open will fail if another process has opened the file for WRITE access and the client requests a write lock. To display a log file being written to by a daemon process, a client would specify READ_DATA accesses, and would specify no locking. If the server can not provide the locking requested, it MUST fail the request. Now that I've written it, I think maybe I prefer the LOCK variant. What do other people think? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 11:37:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17959 for ; Tue, 9 Sep 2003 11:37:11 -0400 (EDT) Received: (qmail 7426 invoked by uid 605); 9 Sep 2003 15:37:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7419 invoked from network); 9 Sep 2003 15:37:15 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 9 Sep 2003 15:37:15 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h89Fb91c014084; Tue, 9 Sep 2003 09:37:09 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h89Fb86c009689; Tue, 9 Sep 2003 09:37:08 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h89FXSQx017416; Tue, 9 Sep 2003 08:33:28 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h89FXSiR017415; Tue, 9 Sep 2003 08:33:28 -0700 (PDT) Date: Tue, 9 Sep 2003 08:33:27 -0700 From: Nicolas Williams To: Martin Pool Cc: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers Message-ID: <20030909153325.GA17401@binky.central.sun.com> References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> <3F5CE482.5070500@vandyke.com> <20030909112746.250062e9.mbp@sourcefrog.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030909112746.250062e9.mbp@sourcefrog.net> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 09, 2003 at 11:27:46AM +1000, Martin Pool wrote: > On 8 Sep 2003 Joseph Galbraith wrote: > > It's hard to imagine a filesystem where you can specify that when you > create a file, though perhaps it could be supported when creating a > directory. The namespace where case sensitivity matters is the directory's, so at first glance it makes no sense to specify case behaviour on file opens. But I can see case-behaviour-in-file-open as a short cut for checking the case behaviour of the containing directory (e.g., "preserve this new file's name's case or fail if you can't" -> short for "does the directory where this file is to be created preserve case? If yes, then create the file, if not fail"; "open the file that corresponds to name 'Xyz' with case-sensitive matching" -> "does 'Xyz's parent directory preserve case, and if so, does it have a case-sensitive namespace? If yes open file 'Xyz', else fail"). Is such a short cut justified? I think not. > > I don't know about VMS? And maybe others. > > I think VMS is always case-insensitive. > > OS X is an interesting case because it commonly uses both > case-sensitive (UFS) and case-preserving (HFS) filesystems. However > in neither case does the application get to choose which semantics it > wants. All you can do is find out what a particular > directory/filesystem will do. (Linux is similar, although the > case-insensitive filesystems are less often used.) Bingo. I think the client needs to be able to determine the case rules of each directory and otherwise leave it at that (plus, maybe, the case- behaviour-in-file-open conditional). > > What I want is the ability to know whether or not Readme > > and README are the same file. Perhaps the protocol should offer a file and/or file handle equality operation, particularly since there's no "inode" or otherwise "unique" internal identifier attribute (nor can there always be). And/or maybe we could use a glob operation, so the client could glob("Readme"). > > And perhaps I don't really care about illegal characters and names. > > Perhaps it's easier to have clients just try it and see? That's > simpler, more reliable and probably not too expensive. Agreed. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 16:22:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03146 for ; Tue, 9 Sep 2003 16:22:37 -0400 (EDT) Received: (qmail 20911 invoked by uid 605); 9 Sep 2003 20:22:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20895 invoked from network); 9 Sep 2003 20:22:37 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Sep 2003 20:22:37 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2195347 for ietf-ssh@NetBSD.org; Tue, 09 Sep 2003 14:22:36 -0600 Message-ID: <3F5E368B.3090907@vandyke.com> Date: Tue, 09 Sep 2003 14:22:35 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: gssapi-with-mic References: <27490000.1062778373@mariner.pc.cs.cmu.edu> <3F58C60E.5090201@vandyke.com> In-Reply-To: <3F58C60E.5090201@vandyke.com> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Do we have any implementors of this yet? I'm looking for someone to do interop testing with-- it'd be nice to validate my reading of Jeffrey's notes against someone elses. Thanks, Joseph > Jeffrey Hutzelman wrote: >> OK; I _think_ we may actually have concensus this time. So, here's a >> concrete proposal for what the changes to the spec should look like. >> Hopefully this will be enough for people to comment on and implement >> from, until I can post some real text and submit a draft... >> >> * In section 3 of the -06 document, which describes "gssapi" userauth: >> - Rename the mechanism from "gssapi" to "gssapi-with-mic" >> - When calling GSS_Init_sec_context, the client MUST set integ_req_flag >> - If integ_avail is false, send SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE >> - If integ_avail is true, send SSH_MSG_USERAUTH_GSSAPI_MIC (see below). >> - The server MUST reject the authentication if it gets the wrong message. >> - The server MAY reject authentication anyway if integ_avail is false. >> >> The SSH_MSG_USERAUTH_GSSAPI_MIC message looks like this: >> >> byte SSH_MSG_USERAUTH_GSSAPI_MIC >> string MIC >> >> The MIC is the result of calling GSS_GetMIC on the following: >> >> string session identifier >> byte SSH_MSG_USERAUTH_REQUEST >> string user name >> string service >> string "gssapi-with-mic" >> >> The message number for SSH_MSG_USERAUTH_GSSAPI_MIC is 66. >> I know this is a little different from what Joseph proposed -- what I >> describe actually involves using a different message depending on >> whether integrity is available, rather than sending the same message >> with a possibly empty MIC string. I did this to try to make life >> easier for people who are also implementing "gssapi" -- except for the >> method name, the exchange for "gssapi" is exactly the same as for >> "gssapi-with-mic" when integrity is not supported. That should make >> it easier to implement both with common code, if desired, and it also >> retains some semblance of documentation of the old method in the >> document. If people would rather see >> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away completely, we can >> use the empty-MIC-string approach instead. >> >> >> * Section 4, describing external-keyx, is replaced entirely. The new >> mechanism is called "gssapi-keyex", and consists of a single message: >> >> byte SSH_MSG_USERAUTH_REQUEST >> string user name >> string service >> string "gssapi-keyex" >> string MIC >> >> The MIC is computed by calling GSS_GetMIC using the context from >> _initial_ key exchange. The context from a rekey is never used; if >> the initial key exchange was not GSSAPI-based, then this method cannot >> be used. The MIC is computed over the following: >> >> string session identifier >> byte SSH_MSG_USERAUTH_REQUEST >> string user name >> string service >> string "gssapi-keyex" >> >> >> >> Reasonable? >> >> -- Jeff >> > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 17:19:47 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05260 for ; Tue, 9 Sep 2003 17:19:47 -0400 (EDT) Received: (qmail 24276 invoked by uid 605); 9 Sep 2003 21:19:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24265 invoked from network); 9 Sep 2003 21:19:50 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 9 Sep 2003 21:19:50 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h89LJkPG008416; Tue, 9 Sep 2003 14:19:47 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h89LJjtK020479; Tue, 9 Sep 2003 17:19:45 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h89LJjtd025254; Tue, 9 Sep 2003 17:19:45 -0400 (EDT) Message-Id: <200309092119.h89LJjtd025254@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes In-Reply-To: Your message of "Tue, 09 Sep 2003 23:12:09 +1200." <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Tue, 09 Sep 2003 17:19:45 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > 1. It doesn't involve violating the spec. You just advertise a maximum-size > window (for the SSH level) and read a file as a single large chunk rather > than lots of little bits and pieces (at the SFTP level). Neither violate > the spec. Earlier, you said "ignoring the window". this proposal is significantly different. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 19:17:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11841 for ; Tue, 9 Sep 2003 19:17:09 -0400 (EDT) Received: (qmail 4319 invoked by uid 605); 9 Sep 2003 23:17:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4311 invoked from network); 9 Sep 2003 23:17:11 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 9 Sep 2003 23:17:11 -0000 Received: from mindrot.org (116.195.20.10.dhcp.netstarnetworks.com [10.20.195.116] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h89NJsm03111; Wed, 10 Sep 2003 09:19:56 +1000 Message-ID: <3F5E5F3A.2040205@mindrot.org> Date: Wed, 10 Sep 2003 09:16:10 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: sommerfeld@east.sun.com, galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes References: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> In-Reply-To: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > 2. Pipelining reads/writes and whatnot is a nice theoretical fix, but the fact > that this problem has been around for what, five years now without anyone > fixing it What implementation? OpenSSH has pipelined transfers for over a year and a half. The code is there for anyone to use... -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 19:20:44 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11950 for ; Tue, 9 Sep 2003 19:20:44 -0400 (EDT) Received: (qmail 6189 invoked by uid 605); 9 Sep 2003 23:20:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6181 invoked from network); 9 Sep 2003 23:20:48 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 9 Sep 2003 23:20:48 -0000 Received: from mindrot.org (116.195.20.10.dhcp.netstarnetworks.com [10.20.195.116] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h89NONm03597; Wed, 10 Sep 2003 09:24:23 +1000 Message-ID: <3F5E6046.70400@mindrot.org> Date: Wed, 10 Sep 2003 09:20:38 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: sommerfeld@east.sun.com, galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes References: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> In-Reply-To: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > 1. It doesn't involve violating the spec. You just advertise a maximum-size > window (for the SSH level) and read a file as a single large chunk rather > than lots of little bits and pieces (at the SFTP level). Neither violate > the spec. What do you do if the file is larger than the defined sftp packet size? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 9 22:46:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17787 for ; Tue, 9 Sep 2003 22:46:11 -0400 (EDT) Received: (qmail 25222 invoked by uid 605); 10 Sep 2003 02:46:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25215 invoked from network); 10 Sep 2003 02:46:11 -0000 Received: from sngrel5.hp.com (192.6.86.210) by mail.netbsd.org with SMTP; 10 Sep 2003 02:46:11 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel5.hp.com (Postfix) with SMTP id 02EE35A1 for ; Wed, 10 Sep 2003 10:46:08 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Wed, 10 Sep 2003 12:46:06 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R6VQWWTV; Wed, 10 Sep 2003 12:46:06 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Wed, 10 Sep 2003 12:46:06 +1000 Received: from localhost ([127.0.0.1] helo=vexed) by vexed with smtp (Exim 3.36 #1 (Debian)) id 19wuzD-0006lU-00 for ; Wed, 10 Sep 2003 12:45:39 +1000 Date: Wed, 10 Sep 2003 12:45:34 +1000 From: Martin Pool To: ietf-ssh@NetBSD.org Subject: Re: Case sensitivity on sftp servers Message-Id: <20030910124534.5dbbf048.mbp@sourcefrog.net> In-Reply-To: <3F5DE97C.2020908@vandyke.com> References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> <3F5CE482.5070500@vandyke.com> <20030909112746.250062e9.mbp@sourcefrog.net> <3F5DE97C.2020908@vandyke.com> Reply-To: ietf-ssh@NetBSD.org X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On 9 Sep 2003 Joseph Galbraith wrote: > Actually, the Win32 CreateFile() api takes a flag: > > FILE_FLAG_POSIX_SEMANTICS Fine, you can create "README" and "Readme". But attempting to copy, delete or rename them, pass them to libraries, or open them from another program might get an error, one file at random, or both depending on how you do it. This does not seem very useful, and reports on the web indicate that people porting from Posix did not find it helpful. This is born out by the Samba experience. Basically every report I know of indicates that trying to be case-sensitive on NT is just thoroughly painful even though it's theoretically supported. I don't think there's any sense in adding specific support to the protocol. If the option is in the protocol then users might try it, but they're likely to be confused and disappointed. Of course if somebody has done case-sensitive NT in production and was happy with the results then I withdraw. > Well, it means you probably have to read the mask before > you write it (like mode bits if you only want to change > the other permissions.) OK, just checking. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 15:44:44 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15610 for ; Wed, 10 Sep 2003 15:44:43 -0400 (EDT) Received: (qmail 8395 invoked by uid 605); 10 Sep 2003 19:44:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8387 invoked from network); 10 Sep 2003 19:44:41 -0000 Received: from mail-in-03.arcor-online.net (151.189.21.43) by mail.netbsd.org with SMTP; 10 Sep 2003 19:44:41 -0000 Received: from localhost.arcor.net (dsl-213-023-020-150.arcor-ip.net [213.23.20.150]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id C561FB8C65; Wed, 10 Sep 2003 21:44:35 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 018772D02C; Wed, 10 Sep 2003 21:44:03 +0200 (CEST) Date: Wed, 10 Sep 2003 21:44:03 +0200 From: Markus Friedl To: "Dan O'Reilly" Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Publickey subsystem draft Message-ID: <20030910194401.GA22576@folly> References: <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Sep 05, 2003 at 12:30:05PM -0600, Dan O'Reilly wrote: > Why not use the methodology used by SSH-KEYGEN? It's simple to implement > and would be in keeping with that used on the server already. the server does not need to see the private key. i also think that the server should _never_ see the private key. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 15:49:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15751 for ; Wed, 10 Sep 2003 15:49:17 -0400 (EDT) Received: (qmail 11850 invoked by uid 605); 10 Sep 2003 19:49:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11840 invoked from network); 10 Sep 2003 19:49:18 -0000 Received: from mail-in-05.arcor-online.net (151.189.21.45) by mail.netbsd.org with SMTP; 10 Sep 2003 19:49:18 -0000 Received: from localhost.arcor.net (dsl-213-023-020-150.arcor-ip.net [213.23.20.150]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 872EE98D50; Wed, 10 Sep 2003 21:49:17 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id F0B1B2D003; Wed, 10 Sep 2003 21:48:45 +0200 (CEST) Date: Wed, 10 Sep 2003 21:48:45 +0200 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030910194845.GB22576@folly> References: <3F58C211.8050605@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F58C211.8050605@vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Sep 05, 2003 at 11:04:17AM -0600, Joseph Galbraith wrote: > We had a discussion of sftp performance. I don't > think we really reached an consensus about a change. > > The following things were brought up: > > o Ignoring channel window makes for a screaming > sftp transfer. (unacceptable, breaks multiplexing.) > > o I proposed a new SSH_FXP_MULTI_READ that would make > it easier to do large data transfers. > > o An implementation hints section with some verbage > about issuing multiple simultaneous read and write > requests to obtain maxmimum performance. > [...] > So, what do we want to do? ignoring the channel window is a very very bad suggestion. annoucements of larger windows is a much better idea. multi-read is not really necessary. an implementation hint should help. openssh's sftp performance has increased considerably after Damien added support for multiple simultaneous requests. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 15:50:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15781 for ; Wed, 10 Sep 2003 15:50:09 -0400 (EDT) Received: (qmail 13885 invoked by uid 605); 10 Sep 2003 19:50:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13874 invoked from network); 10 Sep 2003 19:50:12 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 Sep 2003 19:50:12 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01L0I2PTZBPW8WW193@RAPTOR.PSCCOS.COM> for ietf-ssh@NetBSD.org; Wed, 10 Sep 2003 13:50:08 -0700 (MST) Date: Wed, 10 Sep 2003 13:49:09 -0600 From: "Dan O'Reilly" Subject: Re: Publickey subsystem draft In-reply-to: <20030910194401.GA22576@folly> X-Sender: oreilly@raptor.psccos.com To: Markus Friedl Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Message-id: <5.2.0.9.2.20030910134843.09159880@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list At 01:44 PM 9/10/2003, Markus Friedl wrote: >On Fri, Sep 05, 2003 at 12:30:05PM -0600, Dan O'Reilly wrote: > > Why not use the methodology used by SSH-KEYGEN? It's simple to implement > > and would be in keeping with that used on the server already. > >the server does not need to see the private key. > >i also think that the server should _never_ see the private key. I agree with you, but I missed the point of your message. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 16:28:11 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17186 for ; Wed, 10 Sep 2003 16:28:10 -0400 (EDT) Received: (qmail 9348 invoked by uid 605); 10 Sep 2003 20:28:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9335 invoked from network); 10 Sep 2003 20:28:13 -0000 Received: from anor.ics.muni.cz (147.251.4.35) by mail.netbsd.org with SMTP; 10 Sep 2003 20:28:13 -0000 Received: from dior.ics.muni.cz (dior.ics.muni.cz [147.251.6.10]) by anor.ics.muni.cz (8.12.1/8.12.1) with ESMTP id h8AKSATO025912; Wed, 10 Sep 2003 22:28:10 +0200 Received: from acamara.ics.muni.cz (ppp2294.brno.tiscali.cz [212.90.227.129]) (authenticated as erebor for kouril@acamara with DIGEST-MD5) by dior.ics.muni.cz (8.10.1/8.10.0.Beta12) with ESMTP id h8AKS8m02789; Wed, 10 Sep 2003 22:28:08 +0200 (MEST) Received: (from kouril@localhost) by acamara (8.12.8/8.12.1) id h8AFYGQT029667; Wed, 10 Sep 2003 17:34:16 +0200 From: Daniel Kouril Date: Wed, 10 Sep 2003 17:34:16 +0200 To: Nicolas Williams Cc: ietf-krb-wg@anl.gov, ietf-ssh@NetBSD.org Subject: Re: GSS-APIv2 Extension for Storing Delegated Credentials Message-ID: <20030910153416.GA29630@acamara.ics.muni.cz> References: <20030908150702.GC11118@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030908150702.GC11118@binky.central.sun.com> User-Agent: Mutt/1.3.28i X-Muni-Spam-TestIP: 147.251.6.10 X-Muni-Virus-Test: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Sep 08, 2003 at 08:07:03AM -0700, Nicolas Williams wrote: > I just posted the following I-D, which I think the KRB WG and > implementors of draft-ietf-secsh-gsskeyex may find interesting: > > http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt > > " > Abstract > > This document defines a new function for the GSS-API which allows > applications to store delegated (and other) credentials in the > implicit GSS-API credential store. This is needed for GSS-API > applications to use delegated credentials as they would use other > credentials. > " I'm without Internet connectivity just now, so I can't read it, but according to the abstract it seems to address similar area as the "GSS-API Extensions" draft by GGF (available from http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt). Perhaps it would make sense to coordinate the effort with GGF? Cheers, -- Daniel From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 16:44:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17659 for ; Wed, 10 Sep 2003 16:44:34 -0400 (EDT) Received: (qmail 17272 invoked by uid 605); 10 Sep 2003 20:44:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17265 invoked from network); 10 Sep 2003 20:44:37 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 10 Sep 2003 20:44:37 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8AKiXWb029310; Wed, 10 Sep 2003 14:44:33 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8AKiX6c009573; Wed, 10 Sep 2003 14:44:33 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h8AKesQx018689; Wed, 10 Sep 2003 13:40:54 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h8AKerwI018688; Wed, 10 Sep 2003 13:40:53 -0700 (PDT) Date: Wed, 10 Sep 2003 13:40:53 -0700 From: Nicolas Williams To: Daniel Kouril Cc: ietf-krb-wg@anl.gov, ietf-ssh@NetBSD.org Subject: Re: GSS-APIv2 Extension for Storing Delegated Credentials Message-ID: <20030910204053.GW11118@binky.central.sun.com> Mail-Followup-To: Daniel Kouril , ietf-krb-wg@anl.gov, ietf-ssh@netbsd.org References: <20030908150702.GC11118@binky.central.sun.com> <20030910153416.GA29630@acamara.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030910153416.GA29630@acamara.ics.muni.cz> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Sep 10, 2003 at 05:34:16PM +0200, Daniel Kouril wrote: > On Mon, Sep 08, 2003 at 08:07:03AM -0700, Nicolas Williams wrote: > > I just posted the following I-D, which I think the KRB WG and > > implementors of draft-ietf-secsh-gsskeyex may find interesting: > > > > http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt > I'm without Internet connectivity just now, so I can't read it, but according I'll e-mail it to you separately. > to the abstract it seems to address similar area as the "GSS-API Extensions" > draft by GGF (available from > http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt). > Perhaps it would make sense to coordinate the effort with GGF? Unfortunately, the GGF's export-credential-to-environment-variable proposal has a problem: it imposes the use of environment variables as the method for referencing credentials stores, as well as the "current" credential store. In private exchanges with one of the GGF proposal's co-authors it's also become clear that the GGF's proposal implicitly deals with creation of credential stores as well and I think they convinced me that it would be nice to have a generic interface for acquiring handles to credential stores and setting the "current" credential store[*] so that applications can avoid knowledge of mechanism-specific details of how to create a credential store or set the current credential store. But I think such an interface should be described separately from the GSS_Store_cred() described in my I-D , primarily on account of the addition of the concept of credential store management to the GSS-API, which GSS_Store_cred() (and the GSS-APIv2 as it stands) does not require. So, as you can see I've had some exchanges with one co-author of the GGF proposal, some of which was copied to what I think is a GGF mailing list. [*] There's no credential store handle input argument to gss_acquire/add_cred() or gss_init/accept_sec_context(), so there has to be a current credential store context for their use (it could be thread-local, global to a process, global to a login session, global to a host - those being platform-specific details). Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 17:43:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19437 for ; Wed, 10 Sep 2003 17:43:36 -0400 (EDT) Received: (qmail 23358 invoked by uid 605); 10 Sep 2003 21:42:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23351 invoked from network); 10 Sep 2003 21:42:47 -0000 Received: from mail-in-02.arcor-online.net (151.189.21.42) by mail.netbsd.org with SMTP; 10 Sep 2003 21:42:47 -0000 Received: from localhost.arcor.net (dsl-213-023-020-150.arcor-ip.net [213.23.20.150]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id C2510A70A2; Wed, 10 Sep 2003 23:45:50 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 36E6E2D003; Wed, 10 Sep 2003 23:42:14 +0200 (CEST) Date: Wed, 10 Sep 2003 23:42:13 +0200 From: Markus Friedl To: "Dan O'Reilly" Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Publickey subsystem draft Message-ID: <20030910214213.GA19806@folly> References: <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> <5.2.0.9.2.20030910134843.09159880@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030910134843.09159880@raptor.psccos.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Sep 10, 2003 at 01:49:09PM -0600, Dan O'Reilly wrote: > At 01:44 PM 9/10/2003, Markus Friedl wrote: > >On Fri, Sep 05, 2003 at 12:30:05PM -0600, Dan O'Reilly wrote: > >> Why not use the methodology used by SSH-KEYGEN? It's simple to implement > >> and would be in keeping with that used on the server already. > > > >the server does not need to see the private key. > > > >i also think that the server should _never_ see the private key. > > I agree with you, but I missed the point of your message. i obviously missed your point as well, sorry. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 17:52:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19561 for ; Wed, 10 Sep 2003 17:52:34 -0400 (EDT) Received: (qmail 1044 invoked by uid 605); 10 Sep 2003 21:52:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1035 invoked from network); 10 Sep 2003 21:52:37 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 10 Sep 2003 21:52:37 -0000 Received: from localhost.arcor.net (dsl-213-023-020-150.arcor-ip.net [213.23.20.150]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 55E229DC0F; Wed, 10 Sep 2003 23:52:36 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id AAEB72D003; Wed, 10 Sep 2003 23:52:04 +0200 (CEST) Date: Wed, 10 Sep 2003 23:52:04 +0200 From: Markus Friedl To: Peter Gutmann Cc: galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030910215204.GA30679@folly> References: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309051756.h85HuRZ22956@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Sep 06, 2003 at 05:56:27AM +1200, Peter Gutmann wrote: > Joseph Galbraith writes: > > >o Ignoring channel window makes for a screaming > > sftp transfer. (unacceptable, breaks multiplexing.) > > It's only unacceptable if you're actually doing multiplexing. If you're just i think it's unacceptable, because it breaks the protocol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 17:56:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19642 for ; Wed, 10 Sep 2003 17:56:04 -0400 (EDT) Received: (qmail 2517 invoked by uid 605); 10 Sep 2003 21:56:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2510 invoked from network); 10 Sep 2003 21:56:08 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 10 Sep 2003 21:56:08 -0000 Received: from localhost.arcor.net (dsl-213-023-020-150.arcor-ip.net [213.23.20.150]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 16E9E9DC25; Wed, 10 Sep 2003 23:56:08 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 77CB72D003; Wed, 10 Sep 2003 23:55:36 +0200 (CEST) Date: Wed, 10 Sep 2003 23:55:36 +0200 From: Markus Friedl To: Peter Gutmann Cc: sommerfeld@east.sun.com, galb@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: Sftp: performance enhancing changes Message-ID: <20030910215536.GB30679@folly> References: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309091112.h89BC9L25085@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 09, 2003 at 11:12:09PM +1200, Peter Gutmann wrote: > 2. Pipelining reads/writes and whatnot is a nice theoretical fix, but the fact > that this problem has been around for what, five years now without anyone > fixing it, it's not a "theoretical fix". both openssh and ssh.com fixed this very early. it was not fixed before, because in the first place cared less about performance than about interoperability. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 10 18:03:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19802 for ; Wed, 10 Sep 2003 18:03:19 -0400 (EDT) Received: (qmail 5993 invoked by uid 605); 10 Sep 2003 22:03:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5984 invoked from network); 10 Sep 2003 22:03:22 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 Sep 2003 22:03:22 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01L0I7CY7L688WW193@RAPTOR.PSCCOS.COM> for ietf-ssh@NetBSD.org; Wed, 10 Sep 2003 16:03:19 -0700 (MST) Date: Wed, 10 Sep 2003 16:01:57 -0600 From: "Dan O'Reilly" Subject: Re: Publickey subsystem draft In-reply-to: <20030910214213.GA19806@folly> X-Sender: oreilly@raptor.psccos.com To: Markus Friedl Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Message-id: <5.2.0.9.2.20030910160029.0914cd78@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030910134843.09159880@raptor.psccos.com> <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86051AC20F@lespaul.process.com> <5.2.0.9.2.20030905122918.01933eb8@raptor.psccos.com> <5.2.0.9.2.20030910134843.09159880@raptor.psccos.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list At 03:42 PM 9/10/2003, Markus Friedl wrote: >On Wed, Sep 10, 2003 at 01:49:09PM -0600, Dan O'Reilly wrote: > > At 01:44 PM 9/10/2003, Markus Friedl wrote: > > >On Fri, Sep 05, 2003 at 12:30:05PM -0600, Dan O'Reilly wrote: > > >> Why not use the methodology used by SSH-KEYGEN? It's simple to > implement > > >> and would be in keeping with that used on the server already. > > > > > >the server does not need to see the private key. > > > > > >i also think that the server should _never_ see the private key. > > > > I agree with you, but I missed the point of your message. > >i obviously missed your point as well, sorry. What I was referring to was the idea that the file naming methodology as used by SSH-KEYGEN on the server system could be used for the files that will hold the various public keys. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 11 04:15:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15169 for ; Thu, 11 Sep 2003 04:15:02 -0400 (EDT) Received: (qmail 27412 invoked by uid 605); 11 Sep 2003 08:15:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27405 invoked from network); 11 Sep 2003 08:15:02 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 11 Sep 2003 08:15:02 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8B3MeZs017702; Thu, 11 Sep 2003 15:22:40 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h8B3O6A21967; Thu, 11 Sep 2003 15:24:06 +1200 Date: Thu, 11 Sep 2003 15:24:06 +1200 Message-Id: <200309110324.h8B3O6A21967@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: djm@mindrot.org, pgut001@cs.auckland.ac.nz Subject: Re: Sftp: performance enhancing changes Cc: galb@vandyke.com, ietf-ssh@NetBSD.org, sommerfeld@east.sun.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list Damien Miller writes: >What implementation? OpenSSH has pipelined transfers for over a year and a >half. The code is there for anyone to use... The existence of a single (with perhaps one or two others) fixed implementation does not imply any real solution to the problem (it's like a guy I know who tells everyone who'll listen that X.500 has been a great success because his company has managed to build an X.500 directory that works OK most of the time). There are still large numbers of implementations out there which get it wrong, and will probably never be fixed because the implementors couldn't be bothered, and that for entire user populations (and I'm specifically thinking Windows here) all they'll ever see is the broken versions. The solution isn't to jump up and down shouting "Look, we managed to get it right even if no-one else has", but to address, in the design, why no-one else is getting it right. In particular in the Windows market, where there's no strong need to replace telnet and FTP (which drove SSH adoption in the Unix world), and SSL support is built into the OS, SSH is going to be a tough sell when people realise that their favourite GUI file manager with SSH enabled moved data five times slower than it does without SSH. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 11 09:24:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21750 for ; Thu, 11 Sep 2003 09:24:09 -0400 (EDT) Received: (qmail 6836 invoked by uid 605); 11 Sep 2003 13:24:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6829 invoked from network); 11 Sep 2003 13:24:10 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 11 Sep 2003 13:24:10 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 09:24:09 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC21F@lespaul.process.com> From: Richard Whalen To: "'pgut001@cs.auckland.ac.nz'" , djm@mindrot.org Cc: galb@vandyke.com, ietf-ssh@NetBSD.org, sommerfeld@east.sun.com Subject: RE: Sftp: performance enhancing changes Date: Thu, 11 Sep 2003 09:24:07 -0400 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 > -----Original Message----- > From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] > Sent: Wednesday, September 10, 2003 11:24 PM > To: djm@mindrot.org; pgut001@cs.auckland.ac.nz > Cc: galb@vandyke.com; ietf-ssh@NetBSD.org; sommerfeld@east.sun.com > Subject: Re: Sftp: performance enhancing changes > > > Damien Miller writes: > > >What implementation? OpenSSH has pipelined transfers for > over a year and a > >half. The code is there for anyone to use... > > The existence of a single (with perhaps one or two others) fixed > implementation does not imply any real solution to the > problem (it's like a > Are you implying that we should re-design anything that does not have a simple solution so that it has a simple solution? Pipelined transfers is a pretty basic concept (and over 25 years old), maybe someone that can't understand it should go back to the basics of computer science. Rich Whalen (speaking for myself) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 11 10:29:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25133 for ; Thu, 11 Sep 2003 10:29:13 -0400 (EDT) Received: (qmail 14592 invoked by uid 605); 11 Sep 2003 14:29:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14585 invoked from network); 11 Sep 2003 14:29:04 -0000 Received: from smtpde03.sap-ag.de (155.56.68.171) by mail.netbsd.org with SMTP; 11 Sep 2003 14:29:04 -0000 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA22283; Thu, 11 Sep 2003 16:28:40 +0200 (MESZ) From: Martin Rex Message-Id: <200309111428.QAA16833@uw1048.wdf.sap-ag.de> Subject: Re: GSS-APIv2 Extension for Storing Delegated Credentials To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 11 Sep 2003 16:28:02 +0200 (MET DST) Cc: kouril@ics.muni.cz, ietf-krb-wg@anl.gov, ietf-ssh@NetBSD.org In-Reply-To: <20030910204053.GW11118@binky.central.sun.com> from "Nicolas Williams" at Sep 10, 3 01:40:53 pm Reply-To: martin.rex@sap.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > > to the abstract it seems to address similar area as the "GSS-API Extensions" > > draft by GGF (available from > > http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt). > > Perhaps it would make sense to coordinate the effort with GGF? > > Unfortunately, the GGF's export-credential-to-environment-variable > proposal has a problem: it imposes the use of environment variables as > the method for referencing credentials stores, as well as the "current" > credential store. I would very much like to give some feedback on the proposal, however I completely underwater these days. :( Here are a few quick problems that come to my mind: GSS-API doesn't distinguish different credential stores, although the new I-D claims that it would. With GSS-API a mechanism is free to use an arbitrary number of different credential stores and employ whatever implementation-specific magic it desires to decide individually which credential stores to use each time an application asks to acquire a credentials handle. My biggest criticism about the SPKM design was that it uses the keypair of the longterm credentials to perform each GSS-API level authentication. This causes some problems when an implementation wants to use RSA-SmartCards for credential storage and crypto-operations: - "Smart"Cards that deserve their name do not ever reveal the private RSA key that they hold. So it is completely impossible to copy credentials that are stored on such smartcards. - Since every single gssapi-level authentication requires access to the longterm credentials, the use of SmartCards in Single Sign-On environments that perform a large amount of gssapi-level security context establishments require unrestricted access to the cards signing/encryption capabilities without additional user intervention, rendering the contained keypair utterly useless for any kind of legally relevant digital signature operations - SPKM 1/2 (rfc2025) doesn't support credential delegation, and when smartcards are used it is physically impossible - Common PC SmartCard (TCos 1.2 and 2.0) readers and SmartCard interfaces use a serial communication interface with 9600 or 19200 baud, which makes all operations involving the SmartCard *EXTREMELY* slow, and the software has to solve the issue of multiple concurrent access from different processes in a Single Sign-On environment (a mutual authentication involving two smartcards with 1024-bit RSA keys take about 20 Seconds...) - when an SPKM-implementation is stupid enough to use RSA digital signatures for Message Integrity Protection of each individual message of application data, then the problem gets exponentially worse. - message protection operations become extremely slow due to PK-operations - it's a real PITA when a SmartCard is involved, in particular the contention with parallel access becomes a nightmare in busy Single Sign-On environments - security context transfer at the GSS-API level must somehow pass along credentials access with the exported context token, the session key(s) alone as in all reasonable GSS-API mechanisms is not sufficient -- again this is particularly "entertaining" problem to solve if credentials are on a SmartCard. Also keep in mind that GSS-API was designed to cover GSS-API mechanisms that live entirely in a TCB and do not reveal krypto keys or credentials (in whatever shape or form and for whatever (political) reason), so both, credential delegation and copying credentials can never be a generic concept for GSS-API fitting the level of the abstraction of the current spec. -Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 11 11:39:48 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28039 for ; Thu, 11 Sep 2003 11:39:48 -0400 (EDT) Received: (qmail 25980 invoked by uid 605); 11 Sep 2003 15:38:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25971 invoked from network); 11 Sep 2003 15:38:35 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 11 Sep 2003 15:38:35 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8BFcQsF008823; Thu, 11 Sep 2003 08:38:26 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8BFcPi7001519; Thu, 11 Sep 2003 09:38:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h8BFYkQx019105; Thu, 11 Sep 2003 08:34:46 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h8BFYjF2019104; Thu, 11 Sep 2003 08:34:45 -0700 (PDT) Date: Thu, 11 Sep 2003 08:34:44 -0700 From: Nicolas Williams To: Martin Rex Cc: kouril@ics.muni.cz, ietf-krb-wg@anl.gov, ietf-ssh@NetBSD.org Subject: Re: GSS-APIv2 Extension for Storing Delegated Credentials Message-ID: <20030911153444.GJ11118@binky.central.sun.com> Mail-Followup-To: Martin Rex , kouril@ics.muni.cz, ietf-krb-wg@anl.gov, ietf-ssh@netbsd.org References: <20030910204053.GW11118@binky.central.sun.com> <200309111428.QAA16833@uw1048.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309111428.QAA16833@uw1048.wdf.sap-ag.de> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Sep 11, 2003 at 04:28:02PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > > to the abstract it seems to address similar area as the "GSS-API Extensions" > > > draft by GGF (available from > > > http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt). > > > Perhaps it would make sense to coordinate the effort with GGF? > > > > Unfortunately, the GGF's export-credential-to-environment-variable > > proposal has a problem: it imposes the use of environment variables as > > the method for referencing credentials stores, as well as the "current" > > credential store. > > I would very much like to give some feedback on the proposal, > however I completely underwater these days. :( > > Here are a few quick problems that come to my mind: Thanks, I very much appreciate the fedback. > GSS-API doesn't distinguish different credential stores, although > the new I-D claims that it would. With GSS-API a mechanism is > free to use an arbitrary number of different credential stores > and employ whatever implementation-specific magic it desires > to decide individually which credential stores to use each time > an application asks to acquire a credentials handle. Right, the GSS-API does not distinguish between credential stores - it merely expects that there is a single credential store available when GSS_Acquire/Add_cred() are invoked or when GSS_C_NO_CREDENTIAL is referenced. But for multi-user platforms there have to be multiple credential stores, even if only one can be currently available for any given call to GSS_Acquire/Add_cred() or reference to GSS_C_NO_CREDENTIAL. The problem is that delegated credentials are not obtained from any store and so are not available for acquisition by GSS_Acquire/Add_cred() or use through references to GSS_C_NO_CREDENTIAL. Making GSS_Accept_sec_context() store delegated credentials in some store would be inappropriate for multi-user platforms - the credential store context for storing delegated credentials should be selected by the application. > My biggest criticism about the SPKM design was that it uses > the keypair of the longterm credentials to perform each > GSS-API level authentication. This causes some problems when > an implementation wants to use RSA-SmartCards for credential > storage and crypto-operations: > > - "Smart"Cards that deserve their name do not ever reveal the private > RSA key that they hold. So it is completely impossible to copy > credentials that are stored on such smartcards. Using secret keys is not the same as revealing them. I.e., it is perfectly possible to implement SPKM w/ smartcards by proxying the relevant encryption/decryption or signature/verification operations to the smartcard. > - Since every single gssapi-level authentication requires access to > the longterm credentials, the use of SmartCards in Single Sign-On Not true for user-2-user situations. > environments that perform a large amount of gssapi-level security > context establishments require unrestricted access to the cards > signing/encryption capabilities without additional user intervention, > rendering the contained keypair utterly useless for any kind of > legally relevant digital signature operations See above about proxying crypto operations to smartcards. > - SPKM 1/2 (rfc2025) doesn't support credential delegation, and > when smartcards are used it is physically impossible PKI credential delegation could be performed by passing a contact address and secret session key where the receipient of the delegated credential would have to proxy uses of the credential to a service at the contact address and use the session key to derive sub-session keys and to authenticate itself. I've described a similar system for Kerberos V credential forwarding in the past either here or at the MIT Kerberos lists (or both - I forget). > - Common PC SmartCard (TCos 1.2 and 2.0) readers and SmartCard interfaces > use a serial communication interface with 9600 or 19200 baud, which > makes all operations involving the SmartCard *EXTREMELY* slow, > and the software has to solve the issue of multiple concurrent > access from different processes in a Single Sign-On environment > (a mutual authentication involving two smartcards with 1024-bit > RSA keys take about 20 Seconds...) I can't speak to this. I really don't see the relevance of the smartcard issues to my proposal for GSS_Store_cred(). [...] > Also keep in mind that GSS-API was designed to cover GSS-API mechanisms > that live entirely in a TCB and do not reveal krypto keys or credentials > (in whatever shape or form and for whatever (political) reason), > so both, credential delegation and copying credentials can never be > a generic concept for GSS-API fitting the level of the abstraction > of the current spec. The GSS_Store_cred() interface does not imply that "physical" credentials (i.e., longterm secrets) are actually stored, nor does it imply that the store is a file, a smartcard or punched cards - not anymore than the GSS-API implies the same. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 11 12:12:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29162 for ; Thu, 11 Sep 2003 12:12:50 -0400 (EDT) Received: (qmail 21234 invoked by uid 605); 11 Sep 2003 16:12:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21227 invoked from network); 11 Sep 2003 16:12:52 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 11 Sep 2003 16:12:52 -0000 Received: from localhost.arcor.net (dsl-213-023-013-150.arcor-ip.net [213.23.13.150]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id BA8B4B8583; Thu, 11 Sep 2003 18:12:50 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id F22852D003; Thu, 11 Sep 2003 18:12:18 +0200 (CEST) Date: Thu, 11 Sep 2003 18:12:18 +0200 From: Markus Friedl To: Peter Gutmann Cc: djm@mindrot.org, galb@vandyke.com, ietf-ssh@NetBSD.org, sommerfeld@east.sun.com Subject: Re: Sftp: performance enhancing changes Message-ID: <20030911161218.GA16296@folly> References: <200309110324.h8B3O6A21967@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309110324.h8B3O6A21967@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Sep 11, 2003 at 03:24:06PM +1200, Peter Gutmann wrote: > The existence of a single (with perhaps one or two others) fixed > implementation does not imply any real solution to the problem (it's like a yes, just most of the implementations have this fixed. > guy I know who tells everyone who'll listen that X.500 has been a great > success because his company has managed to build an X.500 directory that works > OK most of the time). There are still large numbers of implementations out > there which get it wrong, and will probably never be fixed because the > implementors couldn't be bothered, and that for entire user populations (and > I'm specifically thinking Windows here) all they'll ever see is the broken > versions. sure but these implementations have to be fixed in one way or another, so why fix it by breaking the protocol? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 12 18:25:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20484 for ; Fri, 12 Sep 2003 18:25:15 -0400 (EDT) Received: (qmail 20072 invoked by uid 605); 12 Sep 2003 22:25:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20062 invoked from network); 12 Sep 2003 22:25:14 -0000 Received: from asgard.ietf.org (132.151.6.40) by mail.netbsd.org with SMTP; 12 Sep 2003 22:25:14 -0000 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19xwK7-00037q-3h; Fri, 12 Sep 2003 18:23:27 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Using DNS to Securely Publish SSH Key Fingerprints' to Proposed Standard Message-Id: Date: Fri, 12 Sep 2003 18:23:27 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved following document: - 'Using DNS to Securely Publish SSH Key Fingerprints ' as a Proposed Standard This document is the product of the Secure Shell Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes a method to verify Secure Shell (SSH) host keys using DNS security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. Working Group Summary The Secure Shell Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 15 04:18:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17146 for ; Mon, 15 Sep 2003 04:18:06 -0400 (EDT) Received: (qmail 8578 invoked by uid 605); 15 Sep 2003 08:18:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8571 invoked from network); 15 Sep 2003 08:18:01 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 15 Sep 2003 08:18:01 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 031E71EB71; Mon, 15 Sep 2003 10:17:50 +0200 (CEST) Message-ID: <3F657540.8030203@siliconcircus.com> Date: Mon, 15 Sep 2003 10:16:00 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org Cc: ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-03.txt Content-Type: multipart/mixed; boundary="------------070004010006000407090900" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------070004010006000407090900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'd be grateful if you could post the attached submission, which is an update of draft-galb-secsh-publickey-subsystem-02.txt (and is now a secsh WG working item, hence the name change from galb -> ietf). -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------070004010006000407090900 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-03.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-03.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: March 15, 2004 B. McClure VanDyke Software J. Bright Silicon Circus September 15, 2003 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-03.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 March 15, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting a Galbraith, et al. Expires March 15, 2004 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Shell or a Command''. The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . 4 2.1 Opening the Public-Key Subsystem . . . . . . . . . . . . . . 4 2.2 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 The Status Response . . . . . . . . . . . . . . . . . . . . 5 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . 7 3.1 Version Packet . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Adding a public key . . . . . . . . . . . . . . . . . . . . 7 3.3 Removing a public key . . . . . . . . . . . . . . . . . . . 10 3.4 Listing public keys . . . . . . . . . . . . . . . . . . . . 10 3.5 Listing server capabilities . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Galbraith, et al. Expires March 15, 2004 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem September 2003 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires March 15, 2004 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem September 2003 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1 Opening the Public-Key Subsystem The public-key subsystem is opened when the clients sends a SSH_MSG_CHANNEL_REQUEST over an existing session. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" Client implementations SHOULD reject this request; it is normally only sent by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user authenticated with a restricted public key that does not allow access to the publickey subsystem. It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires March 15, 2004 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem September 2003 2.2 Requests All public-key subsystem requests are sent in the following form: uint32 length string request-name ... request specific data follows The length field describes the length of the request-name field and the request-specific data, but not of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. All requests described in Section 3 are a description of the 'request-name' and 'data' portion of the packet. 2.3 Responses All public-key subsystem responses are sent in the following form: uint32 length string response-name ... response specific data follows 2.3.1 The Status Response A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. 2.3.1.1 Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 Galbraith, et al. Expires March 15, 2004 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem September 2003 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 Galbraith, et al. Expires March 15, 2004 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem September 2003 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and command. 3.1 Version Packet Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number The version of the protocol described by this document is version 2. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Both sides MUST wait to receive this version before continuing. 3.2 Adding a public key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED Galbraith, et al. Expires March 15, 2004 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorisation checks the server may perform). This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. Galbraith, et al. Expires March 15, 2004 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem September 2003 "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" Galbraith, et al. Expires March 15, 2004 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem September 2003 "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. 3.3 Removing a public key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 3.4 Listing public keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 3.5 Listing server capabilities If the client wishes to know which key attributes the server supports, it sends: Galbraith, et al. Expires March 15, 2004 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem September 2003 string "listattributes" The server will respond with zero or more of the following responses: string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires March 15, 2004 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem September 2003 4. 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 a mechanism that allows client authentication data to be uploaded and manipulated. 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 [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorise keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires March 15, 2004 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Normative References [1] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-13 (work in progress), January 2002. [2] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-15 (work in progress), March 2002. [3] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-16 (work in progress), February 2002. [4] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 (work in progress), January 2002. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 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 Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: jpv@vandyke.com Galbraith, et al. Expires March 15, 2004 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 EMail: jon@siliconcircus.com Galbraith, et al. Expires March 15, 2004 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 assignees. 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 Galbraith, et al. Expires March 15, 2004 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem September 2003 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 March 15, 2004 [Page 16] --------------070004010006000407090900-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 15 04:31:42 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17433 for ; Mon, 15 Sep 2003 04:31:41 -0400 (EDT) Received: (qmail 16478 invoked by uid 605); 15 Sep 2003 08:31:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16471 invoked from network); 15 Sep 2003 08:31:45 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 15 Sep 2003 08:31:45 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 4E63B1EB71 for ; Mon, 15 Sep 2003 10:31:44 +0200 (CEST) Message-ID: <3F657883.2020508@siliconcircus.com> Date: Mon, 15 Sep 2003 10:29:55 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Agent draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, The current agent draft (draft-ietf-secsh-agent-01.txt) has expired. Is a refresh planned? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 16 05:58:51 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00723 for ; Tue, 16 Sep 2003 05:58:51 -0400 (EDT) Received: (qmail 13405 invoked by uid 605); 16 Sep 2003 09:58:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13397 invoked from network); 16 Sep 2003 09:58:48 -0000 Received: from mystic1.trustcenter.de (193.194.157.34) by mail.netbsd.org with SMTP; 16 Sep 2003 09:58:48 -0000 Received: (from root@localhost) by mystic1.trustcenter.de (8.11.6+Sun/8.11.6) id h8G9wfb14837 for ; Tue, 16 Sep 2003 11:58:41 +0200 (MEST) Received: from venus.trustcenter.de(192.168.202.4) by mystic1.trustcenter.de via csmap (V6.0) id srcAAADVaG_C; Tue, 16 Sep 03 11:58:39 +0200 Received: from trustcenter.de (ew-nla.trustcenter.de [192.168.200.46]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h8G9wdi19027 for ; Tue, 16 Sep 2003 11:58:39 +0200 (MET DST) Message-ID: <3F66DEEC.4050607@trustcenter.de> Date: Tue, 16 Sep 2003 11:59:08 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: smartcard keys and the ssh-agent Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, in the last/current draft of the 'Secure Shell Authentication Agent Protocol' the only way to add a new key to the ssh-agent is by sending the private key blob to the agent. If the key is stored in a smartcard and if it's not extractable this is not possible (at least if the normal private key blobs for rsa keys etc. are used). What about adding an additional message to the agent protocol to deal with hardware keys, for example something like this: .... #define SSH_AGENT_ADD_PKCS11_KEY 214 byte SSH_AGENT_ADD_PKCS11_KEY uint32 pkcs11 slot id string pkcs11 CKA_Id string pin .... 0, 1 or several constraints follow Another possibility would be to define special private key blobs for hardware keys containing, for example, the slot id etc. Comments etc. are welcome Nils From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 16 06:28:51 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01668 for ; Tue, 16 Sep 2003 06:28:51 -0400 (EDT) Received: (qmail 26908 invoked by uid 605); 16 Sep 2003 10:28:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26901 invoked from network); 16 Sep 2003 10:28:55 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 16 Sep 2003 10:28:55 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 072A81EB71; Tue, 16 Sep 2003 12:28:47 +0200 (CEST) Message-ID: <3F66E5DD.9010105@siliconcircus.com> Date: Tue, 16 Sep 2003 12:28:45 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nils Larsch Cc: ietf-ssh@NetBSD.org Subject: Re: smartcard keys and the ssh-agent References: <3F66DEEC.4050607@trustcenter.de> In-Reply-To: <3F66DEEC.4050607@trustcenter.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, Nils Larsch wrote: > > in the last/current draft of the 'Secure Shell Authentication > Agent Protocol' the only way to add a new key to the ssh-agent is > by sending the private key blob to the agent. If the key is stored > in a smartcard and if it's not extractable this is not possible > (at least if the normal private key blobs for rsa keys etc. are > used). What about adding an additional message to the agent > protocol to deal with hardware keys, for example something like > this: It would seem to me that this situation doesn't occur - the agent's on the client side and would already know about any local smartcards. Under what circumstances would the server know about a smartcard that the agent was unaware of? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 16 06:46:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02200 for ; Tue, 16 Sep 2003 06:46:19 -0400 (EDT) Received: (qmail 5038 invoked by uid 605); 16 Sep 2003 10:46:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5031 invoked from network); 16 Sep 2003 10:46:22 -0000 Received: from mystic1.trustcenter.de (193.194.157.34) by mail.netbsd.org with SMTP; 16 Sep 2003 10:46:22 -0000 Received: (from root@localhost) by mystic1.trustcenter.de (8.11.6+Sun/8.11.6) id h8GAkKp15731; Tue, 16 Sep 2003 12:46:20 +0200 (MEST) Received: from venus.trustcenter.de(192.168.202.4) by mystic1.trustcenter.de via csmap (V6.0) id srcAAA64aqUE; Tue, 16 Sep 03 12:46:19 +0200 Received: from trustcenter.de (ew-nla.trustcenter.de [192.168.200.46]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h8GAkIi21498; Tue, 16 Sep 2003 12:46:19 +0200 (MET DST) Message-ID: <3F66EA18.2070906@trustcenter.de> Date: Tue, 16 Sep 2003 12:46:48 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Bright CC: ietf-ssh@NetBSD.org Subject: Re: smartcard keys and the ssh-agent References: <3F66DEEC.4050607@trustcenter.de> <3F66E5DD.9010105@siliconcircus.com> In-Reply-To: <3F66E5DD.9010105@siliconcircus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jon Bright wrote: > Hi, > > Nils Larsch wrote: > >> >> in the last/current draft of the 'Secure Shell Authentication >> Agent Protocol' the only way to add a new key to the ssh-agent is >> by sending the private key blob to the agent. If the key is stored >> in a smartcard and if it's not extractable this is not possible >> (at least if the normal private key blobs for rsa keys etc. are >> used). What about adding an additional message to the agent >> protocol to deal with hardware keys, for example something like >> this: > > > It would seem to me that this situation doesn't occur - the agent's on > the client side and would already know about any local smartcards. Under And how should the client add a smartcard key (for example using OpenSSH's ssh-add(1)) to the agent ? How should the agent know anything about local smartcards ? Nils From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 17 13:38:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21313 for ; Wed, 17 Sep 2003 13:38:48 -0400 (EDT) Received: (qmail 15106 invoked by uid 605); 17 Sep 2003 17:38:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15099 invoked from network); 17 Sep 2003 17:38:42 -0000 Received: from asgard.ietf.org (132.151.6.40) by mail.netbsd.org with SMTP; 17 Sep 2003 17:38:42 -0000 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19zgG4-0007E3-N3; Wed, 17 Sep 2003 13:38:28 -0400 X-test-idtracker: no To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: The IESG Subject: Last Call: 'Generic Message Exchange Authentication For SSH' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Wed, 17 Sep 2003 13:38:28 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has received a request from the Secure Shell WG to consider the following document: - 'Generic Message Exchange Authentication For SSH ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 18 00:09:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12938 for ; Thu, 18 Sep 2003 00:09:37 -0400 (EDT) Received: (qmail 24002 invoked by uid 605); 18 Sep 2003 04:09:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23978 invoked from network); 18 Sep 2003 04:09:30 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Sep 2003 04:09:30 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.9) with ESMTP id h8I48uqj001149; Wed, 17 Sep 2003 21:08:57 -0700 Received: from moma.corp.google.com (localhost [127.0.0.1]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h8I48uc5004996; Wed, 17 Sep 2003 21:08:56 -0700 Received: (from frank@localhost) by moma.corp.google.com (8.12.9/8.12.3) id h8I48tBZ004995; Wed, 17 Sep 2003 21:08:55 -0700 Date: Wed, 17 Sep 2003 21:08:55 -0700 From: Frank Cusack To: iesg@ietf.org Cc: ietf-ssh@NetBSD.org Subject: Re: Last Call: 'Generic Message Exchange Authentication For SSH' to Proposed Standard Message-ID: <20030917210855.A2185@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from iesg-secretary@ietf.org on Wed, Sep 17, 2003 at 01:38:28PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Sep 17, 2003 at 01:38:28PM -0400, The IESG wrote: > The IESG has received a request from the Secure Shell WG to consider the > following document: > > - 'Generic Message Exchange Authentication For SSH ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-01. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt > typographical/grammatical changes only (from my nroff source): $ rcsdiff -r1.5 -r1.7 -u pwplus.n =================================================================== RCS file: RCS/pwplus.n,v retrieving revision 1.5 retrieving revision 1.7 diff -u -r1.5 -r1.7 --- pwplus.n 2003/04/29 06:03:05 1.5 +++ pwplus.n 2003/08/06 09:36:47 1.7 @@ -83,7 +83,7 @@ 1. Introduction The SSH authentication protocol \%[SSH-USERAUTH] is a general-purpose user -authentication protocol. It is intended to be run over the SSH transport +authentication protocol. It is intended to be run over the SSH transport layer protocol \%[SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection. @@ -178,7 +178,7 @@ does not support the requested language is implementation-dependent. The submethods field is included so the user can give a hint of which -actual methods he wants to use. It is a a comma-separated list of +actual methods he wants to use. It is a comma-separated list of authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods @@ -186,7 +186,7 @@ the empty string. The actual names of the submethods is something which the user and the -server needs to agree upon. +server need to agree upon. Server interpretation of the submethods field is implementation-dependent. @@ -221,7 +221,7 @@ The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST -message outstanding. That is, it may not send another request before +message outstanding. That is, it may not send another request before the client has answered. .KS @@ -293,7 +293,7 @@ the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be -an obvious indication that such truncation has occured. The instruction +an obvious indication that such truncation has occurred. The instruction field SHOULD NOT be truncated. Clients SHOULD use control character filtering as discussed in \%[SSH-ARCH] @@ -363,7 +363,7 @@ If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending to the client. It is suspected that implementations are likely to make the time delay -a configurable, a suggested default is 2 seconds. +configurable; a suggested default is 2 seconds. .ti 0 4. Authentication Examples @@ -485,7 +485,7 @@ .ti 0 6. Security Considerations -The authentication protocol, and this authentication method, depends +The authentication protocol, and this authentication method, depend on the security of the underlying SSH transport layer. Without the confidentiality provided therein, any authentication data passed with this method is subject to interception. @@ -494,8 +494,8 @@ authentication using this method may be variable. It is possible that an observer may gain valuable information simply by counting that number. For example, an observer may guess that a user's password has expired, -and with further observation may be able to determine the frequency of -a site's password expiration policy. +and with further observation may be able to determine the password lifetime +imposed by a site's password expiration policy. .KS .ti 0 @@ -561,7 +561,7 @@ .in 3 .KS .ti 0 -8. Author's Addresses +8. Authors' Addresses .nf .ne 5 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 22 21:06:08 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20635 for ; Mon, 22 Sep 2003 21:06:07 -0400 (EDT) Received: (qmail 13923 invoked by uid 605); 23 Sep 2003 01:06:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13915 invoked from network); 23 Sep 2003 01:06:05 -0000 Received: from sngrel4.hp.com (192.6.86.110) by mail.netbsd.org with SMTP; 23 Sep 2003 01:06:05 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel4.hp.com (Postfix) with SMTP id 0174067 for ; Tue, 23 Sep 2003 09:06:03 +0800 (SST) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 23 Sep 2003 11:06:02 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id SYNDQYS4; Tue, 23 Sep 2003 11:06:01 +1000 Received: from 16.176.65.141 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 23 Sep 2003 11:06:01 +1000 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 1A1bc5-00062t-00 for ; Tue, 23 Sep 2003 11:05:09 +1000 Date: Tue, 23 Sep 2003 11:05:09 +1000 From: Martin Pool To: ietf-ssh@NetBSD.org Subject: SFTP case sensitivity and rename semantics Message-ID: <20030923010507.GH23025@vexed.ozlabs.hp.com> References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> <3F5CE482.5070500@vandyke.com> <20030909112746.250062e9.mbp@sourcefrog.net> <20030909153325.GA17401@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030909153325.GA17401@binky.central.sun.com> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list In the threads about rename and case sensitivity last month, we seemed to reach consensus amongst the people who posted. Will the revised draft paragraphs be added to the standard? -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 22 21:46:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22199 for ; Mon, 22 Sep 2003 21:46:59 -0400 (EDT) Received: (qmail 5712 invoked by uid 605); 23 Sep 2003 01:47:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5705 invoked from network); 23 Sep 2003 01:47:04 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 23 Sep 2003 01:47:04 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa27796; 22 Sep 2003 21:46 EDT Date: Mon, 22 Sep 2003 21:46:54 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: gsskeyex-07 Message-ID: <81400000.1064281614@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I have just sent a new version of the gsskeyex draft to the secretariat for publication. This version takes into account most of the comments received during the previous last call, and also includes the user authentication changes which were discussed here in the past few weeks. Particularly, it includes gssapi-with-mic and gssapi-keyex user auth methods as described in my message of September 5. This absolutely will not be the last version of this draft. It _still_ needs an updated security considerations section, and I'd additionally like to ask all those who commented during the previous last call period to check to be sure their issues were addressed. I'd also like folks to pay particular attention to the new user auth methods, to make sure no other problems have come up. It is my goal to publish another verison of this document before the I-D submission cutoff for the November IETF meeting, so that last call can begin during or shortly after that meeting. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 23 09:58:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13623 for ; Tue, 23 Sep 2003 09:58:15 -0400 (EDT) Received: (qmail 19507 invoked by uid 605); 23 Sep 2003 13:56:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19493 invoked from network); 23 Sep 2003 13:56:26 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 23 Sep 2003 13:56: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 JAA13503; Tue, 23 Sep 2003 09:56:18 -0400 (EDT) Message-Id: <200309231356.JAA13503@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-07.txt Date: Tue, 23 Sep 2003 09:56:18 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol Author(s) : J. Hutzelman, J. Salowey, J. Galbraith, V. Welch Filename : draft-ietf-secsh-gsskeyex-07.txt Pages : 32 Date : 2003-9-23 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-07.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-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-23101627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-23101627.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 23 11:16:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19577 for ; Tue, 23 Sep 2003 11:16:40 -0400 (EDT) Received: (qmail 28477 invoked by uid 605); 23 Sep 2003 15:16:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28424 invoked from network); 23 Sep 2003 15:16:40 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 23 Sep 2003 15:16:40 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2262306; Tue, 23 Sep 2003 09:16:40 -0600 Message-ID: <3F7063D7.8040005@vandyke.com> Date: Tue, 23 Sep 2003 09:16:39 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Pool CC: ietf-ssh@NetBSD.org Subject: Re: SFTP case sensitivity and rename semantics References: <63D30D6E10CFD11190A90000F805FE86051AC212@lespaul.process.com> <20030908122044.5e9dafca.mbp@sourcefrog.net> <3F5CE482.5070500@vandyke.com> <20030909112746.250062e9.mbp@sourcefrog.net> <20030909153325.GA17401@binky.central.sun.com> <20030923010507.GH23025@vexed.ozlabs.hp.com> In-Reply-To: <20030923010507.GH23025@vexed.ozlabs.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > In the threads about rename and case sensitivity last month, we seemed > to reach consensus amongst the people who posted. Will the revised > draft paragraphs be added to the standard? Yes. I'm working on a number of revisions to the draft. I'd hoped to have it out by last week-- now I hope to have it out sometime this week :-) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 24 21:15:51 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18099 for ; Wed, 24 Sep 2003 21:15:51 -0400 (EDT) Received: (qmail 9560 invoked by uid 605); 25 Sep 2003 01:15:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9553 invoked from network); 25 Sep 2003 01:15:51 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 25 Sep 2003 01:15:51 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Sep 2003 03:14:26 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8P1Fl5L008933 for ; Thu, 25 Sep 2003 03:15:48 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id CAA07897 for ietf-ssh@netbsd.org; Thu, 25 Sep 2003 02:15:39 +0100 (BST) Date: Thu, 25 Sep 2003 02:15:39 +0100 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: A proposal for OPEN Message-ID: <20030925021539.N7665@edinburgh.cisco.com> References: <3F5D12CA.7030908@vandyke.com> <751432704.1063078896@mariner.pc.cs.cmu.edu> <3F5DF1B8.8010303@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3F5DF1B8.8010303@vandyke.com>; from galb-list@vandyke.com on Tue, Sep 09, 2003 at 09:28:56AM -0600 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 09, 2003 at 09:28:56AM -0600, Joseph Galbraith wrote: > Another alternative would be to reverse the fields (I'm > familiar with the windows varient, but remember a time > when I found them frustrating.) Would people find the > following easier to parse: > > ACCESS_READ_LOCK > ACCESS_WRITE_LOCK > ACCESS_DELETE_LOCK Well if you want to add locking, I prefer the above style. But you also have the issue of mandatory vs advisory locks... DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 25 13:44:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09016 for ; Thu, 25 Sep 2003 13:44:27 -0400 (EDT) Received: (qmail 681 invoked by uid 605); 25 Sep 2003 17:43:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 659 invoked from network); 25 Sep 2003 17:43:25 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 25 Sep 2003 17:43:25 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2271019; Thu, 25 Sep 2003 11:43:23 -0600 Message-ID: <3F73293B.3040704@vandyke.com> Date: Thu, 25 Sep 2003 11:43:23 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Fawcus CC: ietf-ssh@NetBSD.org Subject: Re: A proposal for OPEN References: <3F5D12CA.7030908@vandyke.com> <751432704.1063078896@mariner.pc.cs.cmu.edu> <3F5DF1B8.8010303@vandyke.com> <20030925021539.N7665@edinburgh.cisco.com> In-Reply-To: <20030925021539.N7665@edinburgh.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Derek Fawcus wrote: > On Tue, Sep 09, 2003 at 09:28:56AM -0600, Joseph Galbraith wrote: > >>Another alternative would be to reverse the fields (I'm >>familiar with the windows varient, but remember a time >>when I found them frustrating.) Would people find the >>following easier to parse: >> >> ACCESS_READ_LOCK >> ACCESS_WRITE_LOCK >> ACCESS_DELETE_LOCK > > Well if you want to add locking, I prefer the above style. Yes; I had settled on these. > But you also have the issue of mandatory vs advisory locks... I've heard these terms before, but I'm not sure I've had them clearly defined for me before. Let me see if I'm anyplace close on what they mean :-) Mandatory Lock ============== Once I am granted a mandatory lock, I own it until I release it. Others trying to access the file in a way that conflicts with my lock will receive an error. Advisory Lock ============= Once I am granted an advisory lock, I own it until either I release it or the server notifies me that it is breaking my lock. Others trying to access the file in a way that conflicts with my lock will result in the server breaking my lock. Is this any place close to what these terms mean? Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 25 13:54:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09719 for ; Thu, 25 Sep 2003 13:54:53 -0400 (EDT) Received: (qmail 11964 invoked by uid 605); 25 Sep 2003 17:54:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11938 invoked from network); 25 Sep 2003 17:54:48 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 25 Sep 2003 17:54:48 -0000 Received: from edi-view2.cisco.com (edi-view2.cisco.com [144.254.112.71]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8PHsjwn014894; Thu, 25 Sep 2003 10:54:46 -0700 (PDT) Received: (dfawcus@localhost) by edi-view2.cisco.com (8.11.2/CISCO.WS.1.2) id h8PHsi529294; Thu, 25 Sep 2003 18:54:44 +0100 (BST) Date: Thu, 25 Sep 2003 18:54:44 +0100 From: Derek Fawcus To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: A proposal for OPEN Message-ID: <20030925185443.B8218@edi-view2.cisco.com> References: <3F5D12CA.7030908@vandyke.com> <751432704.1063078896@mariner.pc.cs.cmu.edu> <3F5DF1B8.8010303@vandyke.com> <20030925021539.N7665@edinburgh.cisco.com> <3F73293B.3040704@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3F73293B.3040704@vandyke.com>; from galb-list@vandyke.com on Thu, Sep 25, 2003 at 11:43:23AM -0600 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Sep 25, 2003 at 11:43:23AM -0600, Joseph Galbraith wrote: > Derek Fawcus wrote: > > But you also have the issue of mandatory vs advisory locks... > > I've heard these terms before, but I'm not sure I've had them > clearly defined for me before. Let me see if I'm anyplace close > on what they mean :-) > > Mandatory Lock > ============== > Once I am granted a mandatory lock, I own it until > I release it. Others trying to access the file in > a way that conflicts with my lock will receive an > error. > > Advisory Lock > ============= > Once I am granted an advisory lock, I own it until > either I release it or the server notifies me that > it is breaking my lock. Others trying to access the > file in a way that conflicts with my lock will result > in the server breaking my lock. > > Is this any place close to what these terms mean? Well I was think more of the unix type advisory vs mandatory locks, whereby with advisory locks, locking is only implemented if requested, i.e. process 1 opens the file, requests a lock, does i/o process 2 opens the file, does i/o if the kernel only implements advisory locks, then process 2 can (because it has no knowledge of the locking) interfere with the i/o of process 1. Furthermore process 1 never gets to find out. So on a system that only implemented advisory locking, having a file accessed by SFTP (with locks) would not protect against a local process manipulating the file. This local process could well be another SFTP instance, or could be as simple as someone truncating the file from a shell prompt with '> filename'. Mandatory locks are as you describe - once locked other's can't interfere. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 26 18:29:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27392 for ; Fri, 26 Sep 2003 18:29:24 -0400 (EDT) Received: (qmail 2743 invoked by uid 605); 26 Sep 2003 22:29:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2736 invoked from network); 26 Sep 2003 22:29:25 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 26 Sep 2003 22:29:25 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1A315Z-0004H6-00; Fri, 26 Sep 2003 23:29:25 +0100 Date: Fri, 26 Sep 2003 23:29:25 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Minor comments on draft-ietf-secsh-filexfer-04 Message-ID: <20030926222925.GA15376@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Section 5.5 "Permissions": "...as defined by POSIX [1]": [1] isn't POSIX. It would also be nice to have the relevant bit quoted so the draft stands without POSIX. Section 5.6 "Times": "A negative value..." [for atime etc]: atime and friends are defined as `uint64' in sec 5. From draft-ietf-secsh-architecture-14, `uint64' "represents a 64-bit unsigned integer", so can't go negative. The architecture draft doesn't define signed types, so some words indicating that that the putative "uint64" is to be treated as 2's complement signed yadda yadda are probably needed. Section 6.11 "Canonicalizing the Server-Side Path Name" (SSH_FXP_REALPATH): It's not too clear how much of the path needs to exist at the time REALPATH is invoked. This may cause interoperability problems. At least one implementation (psftp) contains workarounds to handle variant server responses to REALPATH("../path/to/nonexistent") where "../path/to" exists but the path component "nonexistent" doesn't (for instance when the client is planning to create a file or directory). Some servers will apparently complain because "nonexistent" doesn't exist, whereas others don't mind. Not sure what the right fix is - it's probably more important that it's defined than how it's defined. A conservative one would be to require the path to exist in its entirety (so in the above case, clients would ask about the destination directory, and then splice the filename on the end). This would remove ambiguity about how it's intended to be used; however, there are a few cases where realname(path) + "/" + leaf != realname(path + "/" + leaf) for instance, if the client plans to mkdir(".."). This probably doesn't matter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 26 18:34:39 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27581 for ; Fri, 26 Sep 2003 18:34:39 -0400 (EDT) Received: (qmail 5440 invoked by uid 605); 26 Sep 2003 22:34:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5433 invoked from network); 26 Sep 2003 22:34:42 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 26 Sep 2003 22:34:42 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1A31Af-0004sr-00; Fri, 26 Sep 2003 23:34:41 +0100 Date: Fri, 26 Sep 2003 23:34:41 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Content type hint proposal for filexfer Message-ID: <20030926223441.GA16719@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN to allow the client to request that the server open a file in text mode. However, no means is provided for the server to advise the client on whether this transfer mode is appropriate. In all cases it is likely up to the user to manually specify which mode to use. In FTP, this has tended to lead to corrupted file transfers when unintentional translation took place, etc. The following proposal allows the server to optionally communicate this information to the client via attributes. (Since it's an attribute, the client can also manipulate it on the server as far as is specified here if it corresponds to metadata there.) To section 5 "File attributes", 2nd para, add: byte content_type present only if flag CONTENT_TYPE To section 5.1 "Flags", add: #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000004 Add new section after section 5.7 "ACL": 5.x Content type The `content_type' field, if present, indicates whether the file is known to be a text file, known _not_ to be a text file, or is of unknown content. When sent from server to client, it acts as a hint to the client as to whether a file should be opened in SSH_FXF_TEXT mode. The following values are defined: #define SSH_FILEXFER_CTYPE_UNKNOWN 0 #define SSH_FILEXFER_CTYPE_BINARY 1 #define SSH_FILEXFER_CTYPE_TEXT 2 and probably add some words to the description of SSH_FXF_TEXT in section 6.3 "Opening, Creating, and Closing Files" -- something like "Clients MAY decide whether to use SSH_FXF_TEXT based on a previously seen `content_type' attribute." (Of course, this could all be easily reformulated as an extension attribute if desired.) Warts with this proposal: It's unfortunate that this can't be made atomic within the existing protocol design; it requires participating clients to do a STAT or similar before OPEN. (In fact, perhaps there should be some guidance on which of STAT or LSTAT to do in this case.) I don't know whether the non-atomicity would be a problem in practice. It's rather tempting to use the IETF's usual content-type notation, "MIME types" (RFCs 2045-9 and related standards). However: - I don't know of any real filesystems which use it. - Consider "multipart/mixed" and friends. - Does everything in "text/*" want to be opened FXF_TEXT? - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? (Excluding composite types like multipart.) - It risks adding further to SFTP's bloat if not specified carefully. We don't want to end up accidentally requiring implementations to contain entire MIME implementations (or more likely, ill-defined subsets thereof with poor interoperability). From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 29 14:23:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02044 for ; Mon, 29 Sep 2003 14:23:21 -0400 (EDT) Received: (qmail 17280 invoked by uid 605); 29 Sep 2003 18:23:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17273 invoked from network); 29 Sep 2003 18:23:19 -0000 Received: from web13103.mail.yahoo.com (216.136.174.148) by mail.netbsd.org with SMTP; 29 Sep 2003 18:23:19 -0000 Message-ID: <20030929182317.87761.qmail@web13103.mail.yahoo.com> Received: from [66.146.11.11] by web13103.mail.yahoo.com via HTTP; Mon, 29 Sep 2003 11:23:17 PDT Date: Mon, 29 Sep 2003 11:23:17 -0700 (PDT) From: diego bowen Subject: ssh tunneling and Java RMI To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hello, I'm using java rmi technology and I would like to use ssh tunneling for security purposes. Can this be accomplished?? I've run into a lot of references regarding HTTP Tunneling but not much on SSH. Could you point me in the right direction? Thank you, Diego __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com