From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 07 17:16:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRyK3-0007UJ-QL for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 17:16:51 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRyK2-0006QL-Ei for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 17:16:51 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1D7B663B264; Fri, 7 Apr 2006 21:16:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ticket.ietf.org (ticket.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id 670C663B150 for ; Fri, 7 Apr 2006 21:16:45 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FRyJw-0000sb-Hc for ietf-ssh@netbsd.org; Fri, 07 Apr 2006 17:16:44 -0400 Subject: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated From: "Scott Blomquist via RT" Reply-To: ietf-action@ietf.org In-Reply-To: Message-ID: X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #85608 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: ietf-admin@techsquare.com To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 07 Apr 2006 17:16:44 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > [jacobn+secsh@chiark.greenend.org.uk - Sun Apr 02 12:41:59 2006]: > > I wrote: > > The only message in 'current' that's not in the copy I sent you is a > > "Welcome to ietf-ssh" message. > > *cough* Of course, the new messages appeared in the archive in short > order, embarrassingly, including the one quoted above. > > > There are five recent messages on the list which are not in the > > archive at > > Now that the month has rolled over, removing the possibility of a race > condition, I have attached a drop-in replacement "2003-03.mail" which > contains the four (not five) missing messages. Once that's in place, > that should be the end of the matter. > > Thanks for your patience. > > All set. Have there been any messages in April. I am not seeing any in the archives. sb. Scott Blomquist. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 07 17:25:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRySj-0004zY-To for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 17:25:49 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRySi-0006hF-G3 for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 17:25:49 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 5CF2963B2D4; Fri, 7 Apr 2006 21:25:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from crunchberry.srv.cs.cmu.edu (CRUNCHBERRY.SRV.CS.CMU.EDU [128.2.203.75]) by mail.netbsd.org (Postfix) with ESMTP id 3EAFE63B150 for ; Fri, 7 Apr 2006 21:25:44 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu (IDENT:U2FsdGVkX18G8WBbAgl6f7yY33JsgU3XbobPnpUbKQA@MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k37JwH2e009115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Apr 2006 15:58:17 -0400 (EDT) Date: Fri, 07 Apr 2006 15:09:38 -0400 From: Jeffrey Hutzelman To: ietf-ssh@netbsd.org cc: Jeffrey Hutzelman Subject: RE: AUTH48 [AH]: RFC 4462 NOW AVAILABLE (fwd) Message-ID: <55476DE93D0C1D93751709D8@mariner.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:0196S0cGEMKeRD7yzxKiLk344W65t+2C1kGeLVLSQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c ---------- Forwarded Message ---------- Date: Friday, April 07, 2006 01:26:40 PM -0400 From: Jeffrey Hutzelman To: "Salowey, Joe" , galb@vandyke.com, welch@mcs.anl.gov Subject: RE: AUTH48 [AH]: RFC 4462 NOW AVAILABLE [Removed rfc-editor; I doubt they care about the technical discussion.] On Friday, April 07, 2006 09:57:52 AM -0700 "Salowey, Joe" wrote: > I agree with Jeffrey's revisions, but I have one additional concern > related to the added text in section 3.2. > > The section says "It is up to the server how it interprets the user name > and determines whether the client is authorized based on his GSS-API > credentials." I don't see anywhere in the document where it states > whether the SSH implementation is required to authorize the user name > against the authenticated credentials or not. This may be better > covered in the SSH base documents, but it is not stated their either. > The reason why I think this is an issue is that applications that are > trying to use SSH as a secure transport such as ISMS are stating that > the SSH user name can be used for authorization purposes. Based on the > current text I'm not sure if it is the responsibility of the SSH > implementation or the ISMS applications to make sure that the user name > is authorized based on the authentication. > > My preference would be to make it clear in the document that the SSH > implementation MUST make sure the user name is allowed based on the name > authenticated by the GSS-API mechanism. Well, RFC4252 doesn't say anything about it because it doesn't really have any concept of an identity other than the username. If you give the wrong password, authentication fails. If you use the wrong public key, authentication fails. And so on. What we have here is a situation where GSS-API authentication can succeed, but you haven't actually authenticated as the requested username, and an authorization check is necessary. I have no objection to text which makes this clear, and I do think it's appropriate for this document. -- Jeff ---------- End Forwarded Message ---------- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 07 19:25:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS0Ks-0006xj-1C for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 19:25:50 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS0Kr-0001d4-JK for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 19:25:50 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 931B663B16E; Fri, 7 Apr 2006 23:25:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from crunchberry.srv.cs.cmu.edu (CRUNCHBERRY.SRV.CS.CMU.EDU [128.2.203.75]) by mail.netbsd.org (Postfix) with ESMTP id 623E263B11F for ; Fri, 7 Apr 2006 23:25:45 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu (IDENT:U2FsdGVkX18pH2pUzjiYM2fo2CaubovmSzvh0e9qIvk@MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k37K1TOY009121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Apr 2006 16:01:30 -0400 (EDT) Date: Fri, 07 Apr 2006 15:09:14 -0400 From: Jeffrey Hutzelman To: ietf-ssh@netbsd.org cc: Jeffrey Hutzelman Subject: RE: AUTH48 [AH]: RFC 4462 NOW AVAILABLE (fwd) Message-ID: <21A4897F5F9E353C9A0C52FB@mariner.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:01CgLoIXRqXZVWTWCiPYAYkKF0H0yRNmF3dxaGQII=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 draft-ietf-secsh-gsskeyex-10.txt is presently in Authors 48 Hours; shortly it will be published as RFC 4462. In the course of final review, Joe Salowey raised an issue related to the need to check that the use of a particular username is authorized when using GSS-API-based user auth. Joe would like to insert a paragraph to address this issue, and I agree. However, it's a substantive change, so Sam would like us to run it by the working group first. I've included Joe's message below, and will forward my own reply under separate cover. We'd like to hear comments from other working group participants. If there are no objections raised by Friday, April 14 (one week from today), then the change Joe proposes below will be included in RFC4462. -- Jeff ---------- Forwarded Message ---------- Date: Friday, April 07, 2006 09:57:52 AM -0700 From: "Salowey, Joe" To: Jeffrey Hutzelman , rfc-editor@rfc-editor.org, galb@vandyke.com, welch@mcs.anl.gov Subject: RE: AUTH48 [AH]: RFC 4462 NOW AVAILABLE I agree with Jeffrey's revisions, but I have one additional concern related to the added text in section 3.2. The section says "It is up to the server how it interprets the user name and determines whether the client is authorized based on his GSS-API credentials." I don't see anywhere in the document where it states whether the SSH implementation is required to authorize the user name against the authenticated credentials or not. This may be better covered in the SSH base documents, but it is not stated their either. The reason why I think this is an issue is that applications that are trying to use SSH as a secure transport such as ISMS are stating that the SSH user name can be used for authorization purposes. Based on the current text I'm not sure if it is the responsibility of the SSH implementation or the ISMS applications to make sure that the user name is authorized based on the authentication. My preference would be to make it clear in the document that the SSH implementation MUST make sure the user name is allowed based on the name authenticated by the GSS-API mechanism. Suggested revision: End of section 3.1 ADD new paragraph "If the authentication succeeds and a non-empty user name is presented by the client the SSH server implementation verifies that the user name is authorized based on the credentials exchanged in the GSS-API exchange. If the user name is not authorized then the authentication MUST fail. " [ Previous messages on editorial changes omitted for ietf-ssh --jhutz] From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 07 20:08:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS10d-0006Tz-U6 for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 20:08:59 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS10b-0003I6-G8 for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Apr 2006 20:08:59 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 014DD63B124; Sat, 8 Apr 2006 00:08:55 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id F299763B11F for ; Sat, 8 Apr 2006 00:08:53 +0000 (UTC) Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k37LWBJO022576 for ; Fri, 7 Apr 2006 15:32:11 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k37LW8dc000951 for ; Fri, 7 Apr 2006 15:32:10 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k37LW8GE009312; Fri, 7 Apr 2006 16:32:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k37LW7mK009311; Fri, 7 Apr 2006 16:32:07 -0500 (CDT) Date: Fri, 7 Apr 2006 16:32:07 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org Subject: Re: AUTH48 [AH]: RFC 4462 NOW AVAILABLE (fwd) Message-ID: <20060407213207.GK8759@binky.Central.Sun.COM> References: <55476DE93D0C1D93751709D8@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55476DE93D0C1D93751709D8@mariner.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab On Fri, Apr 07, 2006 at 03:09:38PM -0400, Jeffrey Hutzelman wrote: > > > ---------- Forwarded Message ---------- > Date: Friday, April 07, 2006 01:26:40 PM -0400 > From: Jeffrey Hutzelman > To: "Salowey, Joe" , galb@vandyke.com, welch@mcs.anl.gov > Subject: RE: AUTH48 [AH]: RFC 4462 NOW > AVAILABLE > > [Removed rfc-editor; I doubt they care about the technical discussion.] > > > On Friday, April 07, 2006 09:57:52 AM -0700 "Salowey, Joe" > wrote: > > >I agree with Jeffrey's revisions, but I have one additional concern > >related to the added text in section 3.2. > > > >The section says "It is up to the server how it interprets the user name > >and determines whether the client is authorized based on his GSS-API > >credentials." I don't see anywhere in the document where it states > >whether the SSH implementation is required to authorize the user name > >against the authenticated credentials or not. This may be better > >covered in the SSH base documents, but it is not stated their either. > >The reason why I think this is an issue is that applications that are > >trying to use SSH as a secure transport such as ISMS are stating that > >the SSH user name can be used for authorization purposes. Based on the > >current text I'm not sure if it is the responsibility of the SSH > >implementation or the ISMS applications to make sure that the user name > >is authorized based on the authentication. > > > >My preference would be to make it clear in the document that the SSH > >implementation MUST make sure the user name is allowed based on the name > >authenticated by the GSS-API mechanism. > > Well, RFC4252 doesn't say anything about it because it doesn't really have > any concept of an identity other than the username. If you give the wrong > password, authentication fails. If you use the wrong public key, > authentication fails. And so on. > > What we have here is a situation where GSS-API authentication can succeed, > but you haven't actually authenticated as the requested username, and an > authorization check is necessary. I have no objection to text which makes > this clear, and I do think it's appropriate for this document. Note: don't be too specific about how this authorization check should be implemented, specifically don't require that authenticated principal's display name or exported MN or gss_compare_name() or anything like that should be used. To speak of the authenticated principal's name generally, or "NAME" (to more clearly reference the object type in RFC2743) is sufficient. This is to keep from accidentally excluding the use of GSS-API naming extensions currently being considered at the KITTEN WG from being used here. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 03:06:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7WF-0001V5-97 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 03:06:03 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7WD-0008Uf-U1 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 03:06:03 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 71E7F63B136; Sat, 8 Apr 2006 07:05:58 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from crunchberry.srv.cs.cmu.edu (CRUNCHBERRY.SRV.CS.CMU.EDU [128.2.203.75]) by mail.netbsd.org (Postfix) with ESMTP id 8776063B127 for ; Sat, 8 Apr 2006 07:05:57 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu (IDENT:U2FsdGVkX1/5w3xYACANHvEWoDkLvc8uY00GLHrVpUk@MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k3875sxJ013024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2006 03:05:55 -0400 (EDT) Date: Fri, 07 Apr 2006 17:42:54 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: AUTH48 [AH]: RFC 4462 NOW AVAILABLE (fwd) Message-ID: <5614B931E7F556CAC94B92D1@mariner.pc.cs.cmu.edu> In-Reply-To: <20060407213207.GK8759@binky.Central.Sun.COM> References: <55476DE93D0C1D93751709D8@mariner.pc.cs.cmu.edu> <20060407213207.GK8759@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01GC2FeYKV+u1keP36S6u16K+fvKSfYf6ForPeTq0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Friday, April 07, 2006 04:32:07 PM -0500 Nicolas Williams wrote: > Note: don't be too specific about how this authorization check should be > implemented, specifically don't require that authenticated principal's > display name or exported MN or gss_compare_name() or anything like that > should be used. To speak of the authenticated principal's name > generally, or "NAME" (to more clearly reference the object type in > RFC2743) is sufficient. We don't even do that. Joe quoted the relevant text, which is already in the document: > It is up to the server how it interprets the user name > and determines whether the client is authorized based on his GSS-API > credentials. All the new text does is require that the check be done in the first place. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 03:06:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7WL-0001ac-TJ for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 03:06:09 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7WL-0008Ul-Hq for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 03:06:09 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4DDAF63B14C; Sat, 8 Apr 2006 07:06:01 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from crunchberry.srv.cs.cmu.edu (CRUNCHBERRY.SRV.CS.CMU.EDU [128.2.203.75]) by mail.netbsd.org (Postfix) with ESMTP id B33CE63B148 for ; Sat, 8 Apr 2006 07:05:58 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu (IDENT:U2FsdGVkX1/5w3xYACANHvEWoDkLvc8uY00GLHrVpUk@MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k3875sxL013024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2006 03:05:55 -0400 (EDT) Date: Fri, 07 Apr 2006 19:05:01 -0400 From: Jeffrey Hutzelman To: ietf-action@ietf.org, ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated Message-ID: <6955D4B559A24A3766C2B89D@mariner.pc.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01v3QetynckysLv5Y48vJOJlbmVeJGqJcs6Uwc9fQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Friday, April 07, 2006 05:16:44 PM -0400 Scott Blomquist via RT wrote: >> [jacobn+secsh@chiark.greenend.org.uk - Sun Apr 02 12:41:59 2006]: >> >> I wrote: >> > The only message in 'current' that's not in the copy I sent you is a >> > "Welcome to ietf-ssh" message. >> >> *cough* Of course, the new messages appeared in the archive in short >> order, embarrassingly, including the one quoted above. >> >> > There are five recent messages on the list which are not in the >> > archive at >> >> Now that the month has rolled over, removing the possibility of a race >> condition, I have attached a drop-in replacement "2003-03.mail" which >> contains the four (not five) missing messages. Once that's in place, >> that should be the end of the matter. >> >> Thanks for your patience. >> >> > > All set. Have there been any messages in April. I am not seeing any in > the archives. Yours was the first, and there have been a few others today. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 03:06:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7WV-0001mi-4O for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 03:06:19 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7WT-0008Ut-Or for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 03:06:19 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 6FE9563B14A; Sat, 8 Apr 2006 07:06:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ticket.ietf.org (ticket.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id 99AAD63B148 for ; Sat, 8 Apr 2006 07:06:02 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FS7WD-0001xM-P9 for ietf-ssh@netbsd.org; Sat, 08 Apr 2006 03:06:01 -0400 Subject: Re: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated From: "Jeffrey Hutzelman via RT" Reply-To: ietf-action@ietf.org In-Reply-To: Message-ID: X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #85608 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: jhutz@cmu.edu To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Sat, 08 Apr 2006 03:06:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Friday, April 07, 2006 05:16:44 PM -0400 Scott Blomquist via RT wrote: >> [jacobn+secsh@chiark.greenend.org.uk - Sun Apr 02 12:41:59 2006]: >> >> I wrote: >> > The only message in 'current' that's not in the copy I sent you is a >> > "Welcome to ietf-ssh" message. >> >> *cough* Of course, the new messages appeared in the archive in short >> order, embarrassingly, including the one quoted above. >> >> > There are five recent messages on the list which are not in the >> > archive at >> >> Now that the month has rolled over, removing the possibility of a race >> condition, I have attached a drop-in replacement "2003-03.mail" which >> contains the four (not five) missing messages. Once that's in place, >> that should be the end of the matter. >> >> Thanks for your patience. >> >> > > All set. Have there been any messages in April. I am not seeing any in > the archives. Yours was the first, and there have been a few others today. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 04:43:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS92q-0000qh-Kz for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 04:43:48 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS92p-0003Zq-6Y for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 04:43:48 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1E3F863B158; Sat, 8 Apr 2006 08:43:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id 4FAE063B151 for ; Sat, 8 Apr 2006 08:43:43 +0000 (UTC) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k386wO3d000628 for ; Sat, 8 Apr 2006 00:58:24 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k386wNdc010383 for ; Sat, 8 Apr 2006 00:58:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k386wNNE009724; Sat, 8 Apr 2006 01:58:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k386wMNF009723; Sat, 8 Apr 2006 01:58:22 -0500 (CDT) Date: Sat, 8 Apr 2006 01:58:22 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: AUTH48 [AH]: RFC 4462 NOW AVAILABLE (fwd) Message-ID: <20060408065821.GS8759@binky.Central.Sun.COM> References: <21A4897F5F9E353C9A0C52FB@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21A4897F5F9E353C9A0C52FB@mariner.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Fri, Apr 07, 2006 at 03:09:14PM -0400, Jeffrey Hutzelman wrote: > draft-ietf-secsh-gsskeyex-10.txt is presently in Authors 48 Hours; shortly > it will be published as RFC 4462. In the course of final review, Joe > Salowey raised an issue related to the need to check that the use of a > particular username is authorized when using GSS-API-based user auth. > > Joe would like to insert a paragraph to address this issue, and I agree. > However, it's a substantive change, so Sam would like us to run it by the > working group first. I've included Joe's message below, and will forward > my own reply under separate cover. We'd like to hear comments from other > working group participants. If there are no objections raised by Friday, > April 14 (one week from today), then the change Joe proposes below will be > included in RFC4462. I support the new text. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 09:41:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSDgW-0007xo-IS for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 09:41:04 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSDgW-0004XA-5S for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 09:41:04 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 14E4763B167; Sat, 8 Apr 2006 13:41:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from irvbhxw03.quest.com (irvbhxw03.quest.com [12.106.87.70]) by mail.netbsd.org (Postfix) with ESMTP id 1403763B12D for ; Sat, 8 Apr 2006 13:41:01 +0000 (UTC) Received: from melbhxw01.oz.quest.com ([10.20.4.113]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Apr 2006 05:39:01 -0700 Received: from melmbxw01.prod.quest.corp ([10.20.4.118]) by melbhxw01.oz.quest.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 8 Apr 2006 22:38:55 +1000 Received: from [10.100.0.16] ([10.20.36.132]) by melmbxw01.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Apr 2006 22:38:55 +1000 Message-ID: <4437AEDD.9000204@quest.com> Date: Sat, 08 Apr 2006 22:38:53 +1000 From: David Leonard User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: empty user name in gsskeyex Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2006 12:38:55.0387 (UTC) FILETIME=[662FA6B0:01C65B09] Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I have some concerns with this under-discussed paragraph in gsskeyex-10 The user name may be an empty string if it can be deduced from the results of the GSSAPI authentication. If the user name is not empty, and the requested user does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentications but never accept any. This makes it possible for the server to avoid disclosing information about which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted. The first sentence mentions a server capability (deducing user names when passed as blank) the status of which isn't clearly described. If the feature isn't useful enough to be included properly, then that sentence should just be deleted. I think that deducing user names /is/ a convenient feature, so I instead suggest that the first sentence be replaced with: If the user name is an empty string, the server MAY deduce the user name from the results of the GSSAPI authentication. And a corresponding provision should also be added to the gssapi-keyex method section (i.e. repeat the above sentence for keyex) This is a pretty useful feature for users in my view. But I am worried that it has too many problems. The current GSSAPI does not provide a way to portably deduce an account name from credentials. (I'm thinking about querying credentials to get a GSS_C_NT_USER_NAME name). Maybe one day it will? But for now, a server must talk magic to its favourite mechanisms. In short, the feature encourages non-standard implementation. That sounds bad to me. I also noticed an interoperability problem. A good client, not provided with a username, will try the empty-username first, and if it fails, assume the server is old and try to deduce a username itself. However, openssh servers prohibit a client from changing the username during authentication. The server immediately disconnects. Is that cause for concern? In short, I don't know if permitting user name deduction is such a great idea with the problems it may cause. But, it would certainly be nice to have. David Leonard From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 12:37:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSGQv-0003Pk-WD for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 12:37:10 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSGQv-0002EX-JC for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 12:37:09 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id AEB8363B1A1; Sat, 8 Apr 2006 16:37:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from crunchberry.srv.cs.cmu.edu (CRUNCHBERRY.SRV.CS.CMU.EDU [128.2.203.75]) by mail.netbsd.org (Postfix) with ESMTP id 853BC63B199 for ; Sat, 8 Apr 2006 16:37:05 +0000 (UTC) Received: from mariner.pc.cs.cmu.edu (IDENT:U2FsdGVkX191Cy8eps1ZbaaUM/ikvD8X/g5WVYgPiCQ@MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k38Gb0SH013431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2006 12:37:03 -0400 (EDT) Date: Sat, 08 Apr 2006 12:37:00 -0400 From: Jeffrey Hutzelman To: David Leonard , ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: empty user name in gsskeyex Message-ID: In-Reply-To: <4437AEDD.9000204@quest.com> References: <4437AEDD.9000204@quest.com> Originator-Info: login-token=Mulberry:01aYO5mtPrLg61zjEbnAHpCQD18MXwtzLW+Of/nwM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 On Saturday, April 08, 2006 10:38:53 PM +1000 David Leonard wrote: > I have some concerns with this under-discussed paragraph in gsskeyex-10 > > The user name may be an empty string if it can be deduced from the > results of the GSSAPI authentication. If the user name is not empty, > and the requested user does not exist, the server MAY disconnect, or > MAY send a bogus list of acceptable authentications but never accept > any. This makes it possible for the server to avoid disclosing > information about which accounts exist. In any case, if the user > does not exist, the authentication request MUST NOT be accepted. > > > The first sentence mentions a server capability (deducing user names when > passed as blank) the status of which isn't clearly described. If the > feature isn't useful enough to be included properly, then that sentence > should just be deleted. > > I think that deducing user names /is/ a convenient feature, so I instead > suggest that the first sentence be replaced with: > > If the user name is an empty string, the server MAY deduce the user > name from the results of the GSSAPI authentication. I don't think this is a substantive change in the protocol; it simply describes the existing feature in a way that doesn't suggest the client should be able to guess at the server's capabilities. > And a corresponding provision should also be added to the gssapi-keyex > method section (i.e. repeat the above sentence for keyex) Just that sentence, without the other three paragraphs about user names from section 3.2? > This is a pretty useful feature for users in my view. But I am worried > that it has too many problems. The current GSSAPI does not provide a way > to portably deduce an account name from credentials. (I'm thinking about > querying credentials to get a GSS_C_NT_USER_NAME name). Maybe one day it > will? I doubt it. The GSS-API is largely about authentication; it doesn't make authorization decisions for applications, including things like which credentials have what access to what "accounts". The form and meaning of usernames is up to the application, and in SSH, it is specific to the server implementation. > But for now, a server must talk magic to its favourite mechanisms. Not magic. A GSS-API acceptor can query a context in a portable way to discover the name of the initiator. And, as Nico points out, there is work in progress to define ways to find out additional information. However, making authorization decisions in inherently application-specific, and in the case of SSH usernames, also implementation-specific. > In short, the feature encourages non-standard implementation. That sounds > bad to me. It encourages servers to define a mapping, or allow the administrator to do so. Since such mappings cannot be standardized in the general case, this is not a problem. > I also noticed an interoperability problem. A good client, not provided > with a username, will try the empty-username first, and if it fails, > assume the server is old and try to deduce a username itself. However, > openssh servers prohibit a client from changing the username during > authentication. The server immediately disconnects. Is that cause for > concern? I don't think so. The SSH specification allows a server to disconnect when a client changes usernames, if the alternative (flushing all authentication state) is too hard for it. So, clients that want to change usernames need to be prepared to establish a new connection if the server terminates the connection on a username change. Note that in the real world, a "normal" client is unlikely to fall back to deducing a username from whatever credentials GSS-API is using. Instead, it is likely to use a name based on the user's local identity on the client system (for example, the value of $USER on a UNIX system). -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 08 14:51:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSIWu-00064d-AL for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 14:51:28 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSIWr-0005zh-Q7 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 08 Apr 2006 14:51:28 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id EB80A63B1BD; Sat, 8 Apr 2006 18:51:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by mail.netbsd.org (Postfix) with ESMTP id 44EA563B134 for ; Sat, 8 Apr 2006 18:51:21 +0000 (UTC) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k38HbNK7017540 for ; Sat, 8 Apr 2006 10:37:24 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38HbNda017227 for ; Sat, 8 Apr 2006 11:37:23 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38HbMkr009973; Sat, 8 Apr 2006 12:37:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38HbMo4009972; Sat, 8 Apr 2006 12:37:22 -0500 (CDT) Date: Sat, 8 Apr 2006 12:37:22 -0500 From: Nicolas Williams To: David Leonard Cc: ietf-ssh@NetBSD.org Subject: Re: empty user name in gsskeyex Message-ID: <20060408173721.GT8759@binky.Central.Sun.COM> References: <4437AEDD.9000204@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4437AEDD.9000204@quest.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 On Sat, Apr 08, 2006 at 10:38:53PM +1000, David Leonard wrote: > I have some concerns with this under-discussed paragraph in gsskeyex-10 > > The user name may be an empty string if it can be deduced from the > results of the GSSAPI authentication. If the user name is not empty, > and the requested user does not exist, the server MAY disconnect, or > MAY send a bogus list of acceptable authentications but never accept > any. This makes it possible for the server to avoid disclosing > information about which accounts exist. In any case, if the user > does not exist, the authentication request MUST NOT be accepted. > > > The first sentence mentions a server capability (deducing user names > when passed as blank) the status of which isn't clearly described. If > the feature isn't useful enough to be included properly, then that > sentence should just be deleted. > > I think that deducing user names /is/ a convenient feature, so I instead > suggest that the first sentence be replaced with: > > If the user name is an empty string, the server MAY deduce the user > name from the results of the GSSAPI authentication. OK, so you want RFC2119 language. I think that's reasonable, if a bit late. > And a corresponding provision should also be added to the gssapi-keyex > method section (i.e. repeat the above sentence for keyex) Sure. > This is a pretty useful feature for users in my view. But I am worried > that it has too many problems. The current GSSAPI does not provide a way > to portably deduce an account name from credentials. (I'm thinking about I doesn't have to. This can be a local matter. And in at least one implementation it is. > querying credentials to get a GSS_C_NT_USER_NAME name). Maybe one day it > will? But for now, a server must talk magic to its favourite mechanisms. Not so. Things one can do: maintain a database of exported name token to username mappings. Nothing mechanism-specific there. Other portable alternatives exist also, but I don't think this RFC should mandate or even recommend any of them. > In short, the feature encourages non-standard implementation. That > sounds bad to me. Local matter. > I also noticed an interoperability problem. A good client, not provided > with a username, will try the empty-username first, and if it fails, > assume the server is old and try to deduce a username itself. Really? For what definition of good? Some clients simply default to whatever the username is on the client side, or in a configuration file. > However, > openssh servers prohibit a client from changing the username during > authentication. The server immediately disconnects. Is that cause for > concern? I don't think it is much of a concern because I think clients should require that the user explicitly choose to assert the empty username. Besides, servers could allow switching from the empty username to one non-empty username. > In short, I don't know if permitting user name deduction is such a great > idea with the problems it may cause. But, it would certainly be nice to > have. I think it's a great idea and it does work. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 09 10:17:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSajk-0001A6-5C for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 09 Apr 2006 10:17:56 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSaji-00083t-Q8 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 09 Apr 2006 10:17:56 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id AF2A263B224; Sun, 9 Apr 2006 14:17:51 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.216.3]) by mail.netbsd.org (Postfix) with ESMTP id 0DCE463B132 for ; Sun, 9 Apr 2006 14:17:49 +0000 (UTC) Received: from hadrian.inf.ed.ac.uk (hadrian.inf.ed.ac.uk [129.215.155.148]) by nutty.inf.ed.ac.uk (8.13.6/8.13.6) with ESMTP id k39CnKoR016310; Sun, 9 Apr 2006 13:49:21 +0100 Received: from hadrian.inf.ed.ac.uk (localhost [127.0.0.1]) by hadrian.inf.ed.ac.uk (8.13.1/8.13.1) with ESMTP id k39CnKw4030242; Sun, 9 Apr 2006 13:49:20 +0100 Received: from localhost (sxw@localhost) by hadrian.inf.ed.ac.uk (8.13.1/8.13.1/Submit) with ESMTP id k39CnILW030239; Sun, 9 Apr 2006 13:49:19 +0100 X-Authentication-Warning: hadrian.inf.ed.ac.uk: sxw owned process doing -bs Date: Sun, 9 Apr 2006 13:49:18 +0100 (BST) From: Simon Wilkinson To: Nicolas Williams cc: David Leonard , ietf-ssh@NetBSD.org Subject: Re: empty user name in gsskeyex In-Reply-To: <20060408173721.GT8759@binky.Central.Sun.COM> Message-ID: References: <4437AEDD.9000204@quest.com> <20060408173721.GT8759@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Sat, 8 Apr 2006, Nicolas Williams wrote: > I doesn't have to. This can be a local matter. And in at least one > implementation it is. For the record, patches existed for OpenSSH which provided this feature (for Kerberos and GSI, at least). It was included in the original code drop that was provided to the OpenSSH folks, but was one of the features removed in the interests of simplifying the code when GSS userauth was integrated. It was implemented in the same way as storage of delegated credentials is implemented - by providing mechanism specific routines. S. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 10 12:35:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSzMJ-0001ZA-VC for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 10 Apr 2006 12:35:23 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSzMJ-0000PA-Fa for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 10 Apr 2006 12:35:23 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 30D1563B1BB; Mon, 10 Apr 2006 16:35:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from CSL-R (105-201.dynamic.dedicado.com.uy [200.108.201.105]) by mail.netbsd.org (Postfix) with SMTP id DB61463B10A for ; Mon, 10 Apr 2006 16:35:13 +0000 (UTC) From: Instituto Latinoamericano de Analisis del Conflicto To: ietf-ssh@netbsd.org Subject: Inseguridad, violencia y el Pacto Por la Paz Social - Manifiesto y Convocatoria. Mime-Version: 1.0 Date: Mon, 10 Apr 2006 16:35:29 GMT Date: Mon, 10 Apr 2006 16:35:29 GMT Content-Type: text/plain; charset="iso-8859-1" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 Message-Id: <20060410163513.DB61463B10A@mail.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 3.3 (+++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 SEGUNDA CARTA DE MONTEVIDEO SOBRE LA VIOLENCIA SOCIAL. 20 TESIS PARA EL PACTO POR LA PAZ SOCIAL. Declaración de Principios y Acciones - Pacto por la Paz Social: El problema de la seguridad pública no es un asunto de Gobierno, sino que es un asunto de Estado. Ello implica la necesidad de retirar el tema del juego electoral y demagógico, donde unos hacen marketing y otros se alimentan, como buitres, de los fracasos. Tratar el problema como Política de Estado permite la convocatoria de una nueva alianza, dentro de un Pacto por la Paz Social, que se refleja en un nuevo aspecto del contrato social, sobre la base de una reforma general y radical de las instituciones involucradas y una inversión muy fuerte en el rescate en especial de la juventud sin opciones y de aquellos que se encuentran en situaciones desesperantes. El presupuesto es simple: no bastan las buenas ideas si no hay capacidad de construir un sistema racional, que pueda ser efectivamente gerenciado. No es posible aplicar una política de seguridad si no hay mecanismos de gestión y operadores capacitados para desarrollarlos. Y no puede haber gestión si no existe una formación y una información calificadas, además de su evaluación permanente. LAS VEINTE TESIS: (el desarrollo de las mismas puede ser solicitado por correo electrónico y se enviarán de inmediato). 1. Contraste evidente entre la relevancia social de la violencia y la inseguridad y la inversión intelectual. 2. Contraste nítido entre la dignidad tradicional y la vulgarización negligente. 3. La concentración en el diagnóstico y el abandono de la práctica, que se refleja en forma directa en la discusión de las políticas públicas. 4. Fijación no reflexionada en una retórica seudo explicativa cuyas consecuencias políticas son graves. 5. La tradición de la denuncia y la inoperancia política y de la sociedad civil, 6. Reacciones automáticas defensivas y corporativas. 7. El movimiento pendular de la ineptitud político - intelectual es el síntoma de la incapacidad de lidiar con el problema de forma persuasiva, eficiente, volviéndola progresivamente irreversible. El principio de la indisociabilidad entre eficiencia y respeto a las leyes y a los derechos humanos. 8. El hueco gigante: ausencia de datos, diagnóstico, planeamiento, evaluación y correcciones para la generación de una experiencia analizable y un conocimiento acumulativo, 9. Los principios elementales en el campo específico de la seguridad. 10. Un ataque directo al problema sistémico para el fortalecimiento democrático. 11. La necesidad de la adopción de análisis y planeamiento cuidadoso de la política de Estado encarnada en la política de seguridad pública. 12. Las diferentes violencias, las semejanzas y las diferencias en nuestra América. Políticas comprensivas y adaptadas a cada situación nacional y local. 13. Impacto de la violencia sobre la economía. 14. Sociedades y países fracturados: poblaciones bajo fuego. 15. La policía como manifestación más tangible del Estado. 16. Las reformas imprescindibles, 17. Las dimensiones simbólico - afectivas. Gobiernos y prensa. 18. Politización suprema y predatoria de la seguridad pública, 19. La seguridad interna es una función irrenunciable del Estado y corresponde a la policía, de la misma manera que la defensa nacional es otra función irrenunciable y corresponde a las Fuerzas Armadas, en consecuencia, los actores no deben ser, jamás, confundidos. LA CONVOCATORIA A LA ACCION: En consecuencia, aquí y ahora, clavamos bandera en el suelo. Vamos, decididos a dar la pelea contra el cáncer que nos carcome. Por eso, esta es la proclama: Pacto por la Paz Social. En este Instituto aguardamos a la sociedad civil, a sus organizaciones representativas y a los ciudadanos, que son los definitivos protagonistas de su destino y de su historia. Todo aquel que comparta los principios de este Manifiesto puede ocupar su lugar, porque todo es necesario y porque todo es útil. En ausencia de política partidaria, en ausencia de afiliación a ideologías, con la excepción de la definitiva afiliación a la cultura de la vida. Cada uno es valioso y nunca seremos demasiados para librar la larga batalla de las ideas que tenemos por delante. Entonces, con serenidad absoluta, con la convicción de la fuerza de las ideas y en la tranquilidad que da la razón, aguardamos, para iniciar el movimiento, en toda la América Latina. Y, que cada quien, se haga cargo de lo que le corresponde. En Montevideo y en Brasilia, a 6 de abril de 2006. Prof. Dr. Ricardo Petrissans de Aguilar. Presidente Instituto Latinoamericano de Análisis del Conflicto. Presidente del Instituto Latinoamericano de Seguridad Pública. Director del Centro de Análisis de Seguridad y Violencia Urbana. INSTITUTO LATINOAMERICANO DE ANALISIS DEL CONFLICTO. CENTRO DE ANALISIS DE LA VIOLENCIA URBANA Y LA SEGURIDAD PÚBLICA. Tristan Narvaja 1729, Montevideo, República Oriental del Uruguay (598-2- 4080618 / 4080628) direccion@ilacon.org www.ilacon.org CLSW 104 Bloco B Sala 123, Ed. Sudoeste Shopping, Brasilia, Distrito Federal, República Federativa del Brasil. (55-61- 3201 7272). escola@escoladenegociacao.org www.escoladenegociacao.org From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 12 15:46:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlI8-0005BT-3h for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 12 Apr 2006 15:46:16 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlI6-000276-SE for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 12 Apr 2006 15:46:16 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 638CF63B1E5; Wed, 12 Apr 2006 19:46:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ticket.ietf.org (ticket.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id 3A1F963B1B8 for ; Wed, 12 Apr 2006 19:46:11 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FTlI2-0003Cd-Ea for ietf-ssh@netbsd.org; Wed, 12 Apr 2006 15:46:10 -0400 Subject: [Inquiry #85608] IETF mailing list archive for SECSH WG not being updated From: "Scott Blomquist via RT" Reply-To: ietf-action@ietf.org In-Reply-To: Message-ID: X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #85608 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: ietf-admin@techsquare.com To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 12 Apr 2006 15:46:10 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed > > Yours was the first, and there have been a few others today. > Resolving this ticket. I think we are now ok. sb. Scott Blomquist From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 12 15:46:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlIH-0005CH-W0 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 12 Apr 2006 15:46:25 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlIH-00027V-Ok for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 12 Apr 2006 15:46:25 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 00BCD63B208; Wed, 12 Apr 2006 19:46:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ticket.ietf.org (ticket.ietf.org [156.154.16.147]) by mail.netbsd.org (Postfix) with ESMTP id 5FC6863B1E2 for ; Wed, 12 Apr 2006 19:46:11 +0000 (UTC) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FTlI2-0003Cg-Ts for ietf-ssh@netbsd.org; Wed, 12 Apr 2006 15:46:10 -0400 Subject: [Inquiry #85608] Resolved: IETF mailing list archive for SECSH WG not being updated From: "Scott Blomquist via RT" Reply-To: ietf-action@ietf.org In-Reply-To: Message-ID: X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #85608 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: ietf-admin@techsquare.com To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 12 Apr 2006 15:46:10 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 13 19:42:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBSQ-0005bR-AP for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Apr 2006 19:42:38 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUBSO-0000o2-TT for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Apr 2006 19:42:38 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 5CC5B63B148; Thu, 13 Apr 2006 23:42:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fleet.cs.ualberta.ca (fleet.cs.ualberta.ca [129.128.22.22]) by mail.netbsd.org (Postfix) with ESMTP id 92A4963B13B for ; Thu, 13 Apr 2006 23:42:32 +0000 (UTC) Received: from fleet.cs.ualberta.ca (localhost.localdomain [127.0.0.1]) by fleet-spampd (Postfix) with ESMTP id 4B50B28006 for ; Thu, 13 Apr 2006 15:44:04 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by fleet-amavis (Postfix) with ESMTP id 3FBC428005 for ; Thu, 13 Apr 2006 15:44:04 -0600 (MDT) Received: from fleet.cs.ualberta.ca ([127.0.0.1]) by localhost (cs.ualberta.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15148-02-74 for ; Thu, 13 Apr 2006 15:44:04 -0600 (MDT) Received: from padstow.cs.ualberta.ca (padstow.cs.ualberta.ca [129.128.23.75]) by fleet.cs.ualberta.ca (Postfix) with ESMTP id 2EBAC28004 for ; Thu, 13 Apr 2006 15:44:04 -0600 (MDT) Received: by padstow.cs.ualberta.ca (Postfix, from userid 16231) id D5ECACF5DF; Thu, 13 Apr 2006 15:44:03 -0600 (MDT) Subject: Stateless SFTP server and READDIR race condition. From: Michael Closson To: iets-ssh Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: University of Alberta Date: Thu, 13 Apr 2006 15:44:02 -0600 Message-Id: <1144964643.4757.99.camel@padstow> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: amavisd-new at cs.ualberta.ca X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on fleet.cs.ualberta.ca X-Spam-Level: X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=failed version=3.0.4 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 This is kind of a nit-pick, but I seems to me that the SFTP server cannot be implemented as a stateless server because the server must track the directory offset to support multiple READDIR calls. Also, there is a potential race condition when there are multiple READDIR calls. NFS READDIR(at least version 2 and 3) returns a cookie to the client, and the client passes the cookie back to the server so the stateless server knows where it left off. NFS version 3 also includes a cookie verifier to detect directory changes that could occur between multiple readdir calls. I'm wondering if this is an issue that should be considered, both the statelessness and detecting directory changes that happen in between SFTP READDIR calls. This is kind of a nit pick for a couple of reasons. First, statelessness is useful for crash recovery, but since NFS is UDP (mostly) and SSH is TCP (always), it is easy for the client to detect a server crash. Second, since SFTP returns multiple directory entries instead of one (as is the case with NFS) the window of vulnerability for directory changes is only an issue for very large directories. Thanks! Mike Closson From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 13 20:29:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCC6-0005WV-Gc for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Apr 2006 20:29:50 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUCC5-0002b7-5b for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Apr 2006 20:29:50 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 71A5263B159; Fri, 14 Apr 2006 00:29:45 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 2D6CB63B134 for ; Fri, 14 Apr 2006 00:29:43 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id UAA10644; Thu, 13 Apr 2006 20:29:41 -0400 (EDT) From: der Mouse Message-Id: <200604140029.UAA10644@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 13 Apr 2006 20:17:55 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Stateless SFTP server and READDIR race condition. In-Reply-To: <1144964643.4757.99.camel@padstow> References: <1144964643.4757.99.camel@padstow> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > This is kind of a nit-pick, but I seems to me that the SFTP server > cannot be implemented as a stateless server because the server must > track the directory offset to support multiple READDIR calls. I don't think you'd want to anyway, because the key exchange and authentication overhead would be insane. Rememebr that SFTP is intended to be used as an SSH subsystem, and it's designed for that environment. While it doesn't necessarily have to be done there, it does mean that its design tradeoffs are partially optimized for that environment. > Also, there is a potential race condition when there are multiple > READDIR calls. Could you detail this? I don't see any race condition unless there are directory-modifying calls involved. > Second, since SFTP returns multiple directory entries instead of one > (as is the case with NFS) ...huh? There's no inherent reason a single NFS READDIR can't return multiple directory entries. A server that refuses to do so when there is space available I would be tempted to call defective, unless there is some unusual justification (such as its running on a microcontroller or some such). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 13 22:24:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUDzB-0000qB-NJ for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Apr 2006 22:24:37 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUDzA-0006bS-BW for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Apr 2006 22:24:37 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 76F5A63B141; Fri, 14 Apr 2006 02:24:33 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id 8966F63B111 for ; Fri, 14 Apr 2006 02:24:32 +0000 (UTC) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3E2OW3d011399 for ; Thu, 13 Apr 2006 20:24:32 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3E2OUdc004349 for ; Thu, 13 Apr 2006 20:24:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3E2OU7P023392; Thu, 13 Apr 2006 21:24:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3E2OTXG023391; Thu, 13 Apr 2006 21:24:29 -0500 (CDT) Date: Thu, 13 Apr 2006 21:24:29 -0500 From: Nicolas Williams To: Michael Closson Cc: iets-ssh Subject: Re: Stateless SFTP server and READDIR race condition. Message-ID: <20060414022429.GR22906@binky.Central.Sun.COM> References: <1144964643.4757.99.camel@padstow> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1144964643.4757.99.camel@padstow> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Thu, Apr 13, 2006 at 03:44:02PM -0600, Michael Closson wrote: > This is kind of a nit-pick, but I seems to me that the SFTP server > cannot be implemented as a stateless server because the server must > track the directory offset to support multiple READDIR calls. Also, > there is a potential race condition when there are multiple READDIR > calls. SFTP needs to decide whether it's a filesystem protocol or a file transfer protocol. Then we can figure out what to do about state recovery across reboots, partitions, etc. A file transfer protocol shouldn't really care about such failures, whereas a filesystem protocol kinda has to. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 14:17:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVulE-0006lV-5j for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:17:12 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVulC-0006pu-Qm for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:17:12 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 90D4763B31B; Tue, 18 Apr 2006 18:17:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 4E7A363B228 for ; Tue, 18 Apr 2006 18:17:06 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA01592; Tue, 18 Apr 2006 14:17:05 -0400 (EDT) From: der Mouse Message-Id: <200604181817.OAA01592@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 18 Apr 2006 14:14:18 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Stateless SFTP server and READDIR race condition. In-Reply-To: <1145381853.4666.29.camel@padstow> References: <1144964643.4757.99.camel@padstow> <200604140029.UAA10644@Sparkle.Rodents.Montreal.QC.CA> <1145381853.4666.29.camel@padstow> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > I guess that stateless doesn't necessarily mean reconnect on every > request. I don't see how it could help it, since the connection is state. > I guess the question becomes, why would one ever want to implement a > stateless server? I don't know. It greatly simiplifies many aspects of crash recovery. >>> Also, there is a potential race condition when there are multiple >>> READDIR calls. >> Could you detail this? I don't see any race condition unless there >> are directory-modifying calls involved. > 1. SFTP OPENDIR causes an opendir() on the server. > 2. 1st SFTP READDIR causes 100 call to readdir(). > 3. Third party modifies directory on server in some arbitrary way. > 4. 2nd SFTP READDIR causes at most 100 additional calls to readdir(). > Entries could be missed. True. But the same applies to any other way of reading a directory on most systems, even including local ls or moral equivalent. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 14:39:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv6e-0003ud-K3 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:39:20 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVv6e-00088I-3x for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:39:20 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id BA1E363B3F4; Tue, 18 Apr 2006 18:39:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by mail.netbsd.org (Postfix) with ESMTP id 8C35F63B3F0 for ; Tue, 18 Apr 2006 18:39:16 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k3IIdFK7016781 for ; Tue, 18 Apr 2006 11:39:16 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3IIdEcc022477 for ; Tue, 18 Apr 2006 12:39:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IIcJJ2001484; Tue, 18 Apr 2006 13:38:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IIcJvS001483; Tue, 18 Apr 2006 13:38:19 -0500 (CDT) Date: Tue, 18 Apr 2006 13:38:19 -0500 From: Nicolas Williams To: Michael Closson Cc: iets-ssh Subject: Re: Stateless SFTP server and READDIR race condition. Message-ID: <20060418183819.GD1274@binky.Central.Sun.COM> References: <1144964643.4757.99.camel@padstow> <20060414022429.GR22906@binky.Central.Sun.COM> <1145383273.4666.50.camel@padstow> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145383273.4666.50.camel@padstow> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Tue, Apr 18, 2006 at 12:01:13PM -0600, Michael Closson wrote: > On Thu, 2006-04-13 at 21:24 -0500, Nicolas Williams wrote: > > SFTP needs to decide whether it's a filesystem protocol or a file > > transfer protocol. Then we can figure out what to do about state > > recovery across reboots, partitions, etc. A file transfer protocol > > shouldn't really care about such failures, whereas a filesystem protocol > > kinda has to. > > Yes, I see your point. > > Readers of this group may be interested in what people are doing with > ssh and sftp. > > My research group at the U of Alberta is involved in a Grid-like project > (i.e., Globus/OGSA). Basically, we want to be able to easily aggregate > multiple HPC (High Performance Computing) systems at the user-level > (also non-root level). A typical use case goes something like this: A > researcher has ssh access to multiple clusters (probably administered by > different groups and there fore no shared file system), and they want to > load-balance some jobs across these clusters. So, we need a nice way to > ship job data back and forth. We have an overlay file system that > presents global view of these multiple systems to application programs. > This overlay file system uses SFTP on the back end. On the front end > (i.e., the interposition agent) we have NFS, Samba, FUSE and a library > that exports a POSIX api (open(), read(), etc.) Just because NFS is typically implemented in kernel-land doesn't mean you can't have one in user-land. In fact, I think there may one or two user-land NFSv4 implementations out there... The same applies to CIFS. And the reverse applies to FTP, and probably to SFTP. The point here is: don't get stuck with the wrong protocol because of any misperceptions you may have. Code availability probably means that it is easier for you to use protocols traditionally implemented for your purposes, but not necessarily, since one of the things you need is thread-safety, and I doubt much off-the-shelf SFTP code is... Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 14:47:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvEW-000692-Mc for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:47:28 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvEU-0008H6-3X for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:47:28 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id BB88363B33B; Tue, 18 Apr 2006 18:47:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sunkay.cs.ualberta.ca (sunkay.cs.ualberta.ca [129.128.4.11]) by mail.netbsd.org (Postfix) with ESMTP id 12A0363B118 for ; Tue, 18 Apr 2006 18:47:19 +0000 (UTC) Received: from padstow.cs.ualberta.ca ([129.128.23.75]:33261 "EHLO padstow") by sunkay.cs.ualberta.ca with ESMTP id S557719AbWDRSBO (ORCPT ); Tue, 18 Apr 2006 12:01:14 -0600 Subject: Re: Stateless SFTP server and READDIR race condition. From: Michael Closson To: Nicolas Williams Cc: iets-ssh In-Reply-To: <20060414022429.GR22906@binky.Central.Sun.COM> References: <1144964643.4757.99.camel@padstow> <20060414022429.GR22906@binky.Central.Sun.COM> Content-Type: text/plain Organization: University of Alberta Date: Tue, 18 Apr 2006 12:01:13 -0600 Message-Id: <1145383273.4666.50.camel@padstow> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Thu, 2006-04-13 at 21:24 -0500, Nicolas Williams wrote: > SFTP needs to decide whether it's a filesystem protocol or a file > transfer protocol. Then we can figure out what to do about state > recovery across reboots, partitions, etc. A file transfer protocol > shouldn't really care about such failures, whereas a filesystem protocol > kinda has to. Yes, I see your point. Readers of this group may be interested in what people are doing with ssh and sftp. My research group at the U of Alberta is involved in a Grid-like project (i.e., Globus/OGSA). Basically, we want to be able to easily aggregate multiple HPC (High Performance Computing) systems at the user-level (also non-root level). A typical use case goes something like this: A researcher has ssh access to multiple clusters (probably administered by different groups and there fore no shared file system), and they want to load-balance some jobs across these clusters. So, we need a nice way to ship job data back and forth. We have an overlay file system that presents global view of these multiple systems to application programs. This overlay file system uses SFTP on the back end. On the front end (i.e., the interposition agent) we have NFS, Samba, FUSE and a library that exports a POSIX api (open(), read(), etc.) Mike From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 14:59:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvPg-0007hV-GN for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:59:00 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvPg-0008Vu-8e for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 14:59:00 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 70E3763B228; Tue, 18 Apr 2006 18:58:58 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 3A85C63B118 for ; Tue, 18 Apr 2006 18:58:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA02013; Tue, 18 Apr 2006 14:58:56 -0400 (EDT) From: der Mouse Message-Id: <200604181858.OAA02013@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 18 Apr 2006 14:54:38 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Stateless SFTP server and READDIR race condition. In-Reply-To: <20060418183819.GD1274@binky.Central.Sun.COM> References: <1144964643.4757.99.camel@padstow> <20060414022429.GR22906@binky.Central.Sun.COM> <1145383273.4666.50.camel@padstow> <20060418183819.GD1274@binky.Central.Sun.COM> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > Just because NFS is typically implemented in kernel-land doesn't mean > you can't have one in user-land. In fact, I think there may one or > two user-land NFSv4 implementations out there... Back in the '80s, I wrote an NFS server that largely runs in user-land. (Not v4, of course, not back then.) It's not totally userland; it has a handful of syscalls to help do things by inumber instead of path - but they're not essential, merely helpful. I could have kept track of paths instead. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 15:54:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwHT-0006uG-SJ for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 15:54:35 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwHR-0002wk-CD for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 15:54:35 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 709CE63B44E; Tue, 18 Apr 2006 19:54:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sunkay.cs.ualberta.ca (sunkay.cs.ualberta.ca [129.128.4.11]) by mail.netbsd.org (Postfix) with ESMTP id 9B5CA63B12F for ; Tue, 18 Apr 2006 19:54:30 +0000 (UTC) Received: from padstow.cs.ualberta.ca ([129.128.23.75]:33234 "EHLO padstow") by sunkay.cs.ualberta.ca with ESMTP id S557652AbWDRRhg (ORCPT ); Tue, 18 Apr 2006 11:37:36 -0600 Subject: Re: Stateless SFTP server and READDIR race condition. From: Michael Closson To: der Mouse Cc: iets-ssh In-Reply-To: <200604140029.UAA10644@Sparkle.Rodents.Montreal.QC.CA> References: <1144964643.4757.99.camel@padstow> <200604140029.UAA10644@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain Organization: University of Alberta Date: Tue, 18 Apr 2006 11:37:33 -0600 Message-Id: <1145381853.4666.29.camel@padstow> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 On Thu, 2006-04-13 at 20:17 -0400, der Mouse wrote: > > This is kind of a nit-pick, but I seems to me that the SFTP server > > cannot be implemented as a stateless server because the server must > > track the directory offset to support multiple READDIR calls. > > I don't think you'd want to anyway, because the key exchange and > authentication overhead would be insane. Rememebr that SFTP is > intended to be used as an SSH subsystem, and it's designed for that > environment. While it doesn't necessarily have to be done there, it > does mean that its design tradeoffs are partially optimized for that > environment. Yes, you are correct. I guess that stateless doesn't necessarily mean reconnect on every request. Although ssh connection sharing (openssh) could be used. I guess the question becomes, why would one ever want to implement a stateless server? I don't know. I made this comment because in the current sftp draft section 8.1 second paragraph it states that sftp open/close allows for the implementation to be either stateful or stateless. open/close may allow this, but readdir doesn't, so there is a small inconsistency with the spec. > > > Also, there is a potential race condition when there are multiple > > READDIR calls. > > Could you detail this? I don't see any race condition unless there are > directory-modifying calls involved. Yes, a third party could modify the directory on the server side. The race condition comes down to this: (I'm using the OpenSSH implementation as a reference). 1. SFTP OPENDIR causes an opendir() on the server. 2. 1st SFTP READDIR causes 100 call to readdir(). 3. Third party modifies directory on server in some arbitrary way. 4. 2nd SFTP READDIR causes at most 100 additional calls to readdir(). Entries could be missed. So, I guess it comes down to the implementation of opendir()/readdir() on the server. Maybe it isn't a problem at all. > > > Second, since SFTP returns multiple directory entries instead of one > > (as is the case with NFS) > > ...huh? There's no inherent reason a single NFS READDIR can't return > multiple directory entries. A server that refuses to do so when there > is space available I would be tempted to call defective, unless there > is some unusual justification (such as its running on a microcontroller > or some such). Opps, looks like my recollection of the NFS protocol is a little hazy. You are correct. I guess the two protocols are similar in this aspect, they each return multiple entries, but maybe not all of them (due to packet size limitations, either an application layer limit or a transport layer limit). Mike Closson From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 16:04:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwQu-0000de-Bq for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 16:04:20 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwQs-0003RH-VQ for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 16:04:20 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1127663B2CA; Tue, 18 Apr 2006 20:04:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id 40CA263B12F for ; Tue, 18 Apr 2006 20:04:16 +0000 (UTC) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3IK4F3d005784 for ; Tue, 18 Apr 2006 14:04:15 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3IK3qda014287 for ; Tue, 18 Apr 2006 14:04:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IJeJIi001581; Tue, 18 Apr 2006 14:40:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IJeJbT001580; Tue, 18 Apr 2006 14:40:19 -0500 (CDT) Date: Tue, 18 Apr 2006 14:40:19 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Stateless SFTP server and READDIR race condition. Message-ID: <20060418194019.GE1274@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <1144964643.4757.99.camel@padstow> <20060414022429.GR22906@binky.Central.Sun.COM> <1145383273.4666.50.camel@padstow> <20060418183819.GD1274@binky.Central.Sun.COM> <200604181858.OAA02013@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604181858.OAA02013@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On Tue, Apr 18, 2006 at 02:54:38PM -0400, der Mouse wrote: > > Just because NFS is typically implemented in kernel-land doesn't mean > > you can't have one in user-land. In fact, I think there may one or > > two user-land NFSv4 implementations out there... > > Back in the '80s, I wrote an NFS server that largely runs in user-land. > (Not v4, of course, not back then.) It's not totally userland; it has > a handful of syscalls to help do things by inumber instead of path - > but they're not essential, merely helpful. I could have kept track of > paths instead. A client wouldn't need anything special... From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 16:25:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwlN-0006N1-B9 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 16:25:29 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwlM-0004YR-0a for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 16:25:29 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 8BFAE63B428; Tue, 18 Apr 2006 20:25:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 58BD763B386 for ; Tue, 18 Apr 2006 20:25:24 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA02699; Tue, 18 Apr 2006 16:25:23 -0400 (EDT) From: der Mouse Message-Id: <200604182025.QAA02699@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 18 Apr 2006 16:23:33 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Stateless SFTP server and READDIR race condition. In-Reply-To: <20060418194019.GE1274@binky.Central.Sun.COM> References: <1144964643.4757.99.camel@padstow> <20060414022429.GR22906@binky.Central.Sun.COM> <1145383273.4666.50.camel@padstow> <20060418183819.GD1274@binky.Central.Sun.COM> <200604181858.OAA02013@Sparkle.Rodents.Montreal.QC.CA> <20060418194019.GE1274@binky.Central.Sun.COM> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 >> Back in the '80s, I wrote an NFS server that largely runs in >> user-land. [...] > A client wouldn't need anything special... No, this was just a server. There was nothing special client-side. (Indeed, if the server conforms to the protocol, it *must* work with nothing-special clients.) This also is rather far from anything ssh-related, so unless something brings it back on-topic, this is my last message on the thread to the list. I'll be happy to discuss it off-list with anyone interested. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 18 19:21:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzVG-00044n-P9 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 19:21:02 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVzVF-0005T4-9i for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Apr 2006 19:21:02 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 0064C63B183; Tue, 18 Apr 2006 23:20:55 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by mail.netbsd.org (Postfix) with ESMTP id DDCB763B109 for ; Tue, 18 Apr 2006 23:20:53 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k3INKrK7024938 for ; Tue, 18 Apr 2006 16:20:53 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3INKqcc029215 for ; Tue, 18 Apr 2006 17:20:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3INKnEn002546; Tue, 18 Apr 2006 18:20:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3INKmn9002545; Tue, 18 Apr 2006 18:20:48 -0500 (CDT) Date: Tue, 18 Apr 2006 18:20:48 -0500 From: Nicolas Williams To: Michael Closson Cc: der Mouse , iets-ssh Subject: Re: Stateless SFTP server and READDIR race condition. Message-ID: <20060418232048.GL1274@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , Michael Closson , der Mouse , iets-ssh References: <1144964643.4757.99.camel@padstow> <200604140029.UAA10644@Sparkle.Rodents.Montreal.QC.CA> <1145381853.4666.29.camel@padstow> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145381853.4666.29.camel@padstow> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, Apr 18, 2006 at 11:37:33AM -0600, Michael Closson wrote: > Yes, you are correct. I guess that stateless doesn't necessarily mean > reconnect on every request. Although ssh connection sharing (openssh) > could be used. I guess the question becomes, why would one ever want to > implement a stateless server? I don't know. Statelessness has got to mean that you can recover from having to reconnect (e.g., because the server or the client rebooted or what have you [in NFSv4 because of network partitions that lasted longer than time periods associated with leases]). > I made this comment because in the current sftp draft section 8.1 second > paragraph it states that sftp open/close allows for the implementation > to be either stateful or stateless. open/close may allow this, but > readdir doesn't, so there is a small inconsistency with the spec. I don't believe what you say about readdir. If a client's connection is reset in the middle of a readdir the client can reconnect and continue, possibly by redoing the readdir completely and comparing to what it had read up to the point where the connection was dropped. In all cases if the protocol lacks any support for file leases and/or directory change notifications then clients may see slightly different file/directory contents. When we talk about stateless filesystem protocols we mean server-side statelessness, not client-side statelessness. I've not combed through it recently, but, at the very least version 3 of SFTP is indeed stateless, to the best of my recollection. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 19 08:50:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWC8F-0005IJ-Py for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 19 Apr 2006 08:50:07 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWC8E-00019I-CD for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 19 Apr 2006 08:50:07 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4A31563B2AB; Wed, 19 Apr 2006 12:50:04 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 4878A63B228 for ; Wed, 19 Apr 2006 12:50:03 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3IIUVZe006899 for ; Tue, 18 Apr 2006 12:30:31 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3IIUUca017168 for ; Tue, 18 Apr 2006 12:30:30 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IIUS6f001475; Tue, 18 Apr 2006 13:30:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IIURkD001474; Tue, 18 Apr 2006 13:30:27 -0500 (CDT) Date: Tue, 18 Apr 2006 13:30:27 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Stateless SFTP server and READDIR race condition. Message-ID: <20060418183027.GC1274@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <1144964643.4757.99.camel@padstow> <200604140029.UAA10644@Sparkle.Rodents.Montreal.QC.CA> <1145381853.4666.29.camel@padstow> <200604181817.OAA01592@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604181817.OAA01592@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, Apr 18, 2006 at 02:14:18PM -0400, der Mouse wrote: > > I guess the question becomes, why would one ever want to implement a > > stateless server? I don't know. > > It greatly simiplifies many aspects of crash recovery. Until you realize that you want locking, and better caching semantics, and... And you realize that none of those things can be done in an entirely stateless manner, that you need to figure out how to deal with client and server crashes as well as network partitions. > >>> Also, there is a potential race condition when there are multiple > >>> READDIR calls. > >> Could you detail this? I don't see any race condition unless there > >> are directory-modifying calls involved. > > 1. SFTP OPENDIR causes an opendir() on the server. > > 2. 1st SFTP READDIR causes 100 call to readdir(). > > 3. Third party modifies directory on server in some arbitrary way. > > 4. 2nd SFTP READDIR causes at most 100 additional calls to readdir(). > > Entries could be missed. > > True. But the same applies to any other way of reading a directory on > most systems, even including local ls or moral equivalent. I suspect that what the above quoted text was getting at is some sort of directory change notification system; go check out the NFSv4 WG list archives for why this is not trivial. BTW, notifications == more state. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 29 12:55:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZsje-0007nN-3a for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Apr 2006 12:55:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZqTp-00017c-6F for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Apr 2006 10:31:29 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZpcx-0006Im-W9 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Apr 2006 09:36:53 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 0094A63B17C; Sat, 29 Apr 2006 09:36:18 -0400 (EDT) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cielago.ip.net.ua (cielago.ip.net.ua [82.193.96.15]) by mail.netbsd.org (Postfix) with ESMTP id B484B63B141 for ; Sat, 29 Apr 2006 09:36:16 -0400 (EDT) Received: from infernal.org.ua (82.193.103.213.ipnet.kiev.ua [82.193.103.213]) by cielago.ip.net.ua (8.13.6/8.13.6) with ESMTP id k3TCZqJu053312 for ; Sat, 29 Apr 2006 15:35:52 +0300 (EEST) (envelope-from ni4@ukr.net) Date: Sat, 29 Apr 2006 15:34:42 +0300 From: "Nickolay L." X-Mailer: The Bat! (v3.0.1.33) Professional Reply-To: "Nickolay L." X-Priority: 3 (Normal) Message-ID: <522175143.20060429153442@ukr.net> To: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-extensions-00.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -1.1 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hello here, In part 4 "Querying Available Space" : In reply, there is possible collision between situation, when 0 bytes available to user (or on device), or this number is unknown. So client would not be able to distinguish situation, when there is no space left on device. Maybe, better meaning of 'unknown' would be UINT64(-1), or so? -- Best regards,Nickolay mailto: , . /_`, `' | &*._.,. .# ) $, //./--//\\. & \/ \. \. -- - - ... - - --. `'`' ` `' -- - - [> http://ansiart.org.ua <]