From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 01 10:21:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7v7p-00019y-M1 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 10:21:37 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7v7o-0006RO-DH for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 10:21:37 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 9D7B663B1ED; Tue, 1 Aug 2006 14:21:01 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id BBE5B63B16D for ; Tue, 1 Aug 2006 14:21:00 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Formal consultation prior to closing the secsh working group X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 1 Aug 2006 10:22:29 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB93BD14D@beacon.PSC.process.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Formal consultation prior to closing the secsh working group Thread-Index: Aca08iV3kaWWpOi8TD6mwST6zUHK5QAgz7vg From: "Richard Whalen" To: "Nicolas Williams" Cc: "Sam Hartman" , , Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Monday, July 31, 2006 6:38 PM > To: Richard Whalen > Cc: Sam Hartman; ietf-ssh@NetBSD.org; housley@vigilsec.com > Subject: Re: Formal consultation prior to closing the secsh working > group >=20 >=20 > On Mon, Jul 31, 2006 at 09:16:38AM -0400, Richard Whalen wrote: > > The Filexfer draft was never a ftp-like protocol. It was=20 > originally a > > file access protocol that was missing a text access method.=20 > After the > > text access method got added it has moved towards becoming=20 > a file system > > protocol. >=20 > IMO, publish the parts of the filexfer protocol that are commonly > implemented as an Informational document (and then only as=20 > Informational > and not targetting Standards-Track if it fails to meet general IETF > requirements, e.g., I18N). >=20 > I don't see why a text access method should be required for a > Standards-Track filexfer protocol for the Secure Shell=20 > protoco, but hey, > I'll take an Informational document over no document at all any day. >=20 A text access method is required because different operating systems store text files in different manners. Text files are commonly transferred between different operating systems so the protocol should include this functionality. I'd be happy with an Informational document as well. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 01 12:02:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7wh3-0006hP-Vu for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 12:02:05 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7wh2-0005hH-My for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 12:02:05 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 9674063B241; Tue, 1 Aug 2006 16:02:01 +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 673E063B1ED for ; Tue, 1 Aug 2006 16:02:00 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k71G1xOg018899 for ; Tue, 1 Aug 2006 10:01:59 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k71FwW9V021659 for ; Tue, 1 Aug 2006 09:58:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k71G1wim021652; Tue, 1 Aug 2006 11:01:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k71G1v0g021651; Tue, 1 Aug 2006 11:01:57 -0500 (CDT) Date: Tue, 1 Aug 2006 11:01:57 -0500 From: Nicolas Williams To: Richard Whalen Cc: Sam Hartman , ietf-ssh@NetBSD.org, housley@vigilsec.com Subject: Re: Formal consultation prior to closing the secsh working group Message-ID: <20060801160156.GO22408@binky.Central.Sun.COM> References: <3EF96AF20489A34296050FBD5C36ECB93BD14D@beacon.PSC.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB93BD14D@beacon.PSC.process.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On Tue, Aug 01, 2006 at 10:22:29AM -0400, Richard Whalen wrote: > A text access method is required because different operating systems > store text files in different manners. Text files are commonly > transferred between different operating systems so the protocol > should include this functionality. A text access method could be nothing more than an optional data type tag. > I'd be happy with an Informational document as well. I'd rather have a Standards-Track document, but I'd settle for Informational. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 01 13:34:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7y8w-0004m7-4E for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 13:34:58 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7y8u-0005j2-MZ for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 13:34:58 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 5E14D63B29B; Tue, 1 Aug 2006 17:34:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by mail.netbsd.org (Postfix) with ESMTP id 46EFB63B29C for ; Tue, 1 Aug 2006 17:34:53 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 021252AC8D; Tue, 1 Aug 2006 15:34:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G7dm5-0007Yz-Ta; Mon, 31 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickey-subsystem-06.txt Message-Id: Date: Mon, 31 Jul 2006 15:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-publickey-subsystem-06.txt Pages : 19 Date : 2006-7-31 Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickey-subsystem-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-31141312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-31141312.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 01 16:13:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80cl-0000UW-Cm for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 16:13:55 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80ck-0002dD-2m for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 16:13:55 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 216FD63B30D; Tue, 1 Aug 2006 20:13:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by mail.netbsd.org (Postfix) with ESMTP id 6BF7163B125 for ; Tue, 1 Aug 2006 20:13:50 +0000 (UTC) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DC7022ACA5; Tue, 1 Aug 2006 20:13:49 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G80cf-0007by-Ks; Tue, 01 Aug 2006 16:13:49 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Document Action: 'SSH Public Key File Format' to Informational RFC Message-Id: Date: Tue, 01 Aug 2006 16:13:49 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The IESG has approved the following document: - 'SSH Public Key File Format ' as an Informational RFC This document is the product of the Secure Shell Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-13.txt Technical Summary This document describes the publickey file format used by many implementations of the ssh protocol. It also describes the format of fingerprints used by ssh implementations. Working Group Summary There was strong consensus to publish this document. Protocol Quality There are several implementation of this specification. This document was reviewed for the IESG by Sam Hartman. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 01 21:09:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G85Ee-0000G8-5D for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 21:09:20 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G85Ec-00069E-RY for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 01 Aug 2006 21:09:20 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 9F5C163B129; Wed, 2 Aug 2006 01:09:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 469ED63B1EB for ; Wed, 2 Aug 2006 01:09:15 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6VMbZxq024411 for ; Mon, 31 Jul 2006 15:37:39 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6VMbZk1022510 for ; Mon, 31 Jul 2006 16:37:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6VMbYTj013598; Mon, 31 Jul 2006 17:37:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6VMbYZs013597; Mon, 31 Jul 2006 17:37:34 -0500 (CDT) Date: Mon, 31 Jul 2006 17:37:34 -0500 From: Nicolas Williams To: Richard Whalen Cc: Sam Hartman , ietf-ssh@NetBSD.org, housley@vigilsec.com Subject: Re: Formal consultation prior to closing the secsh working group Message-ID: <20060731223731.GJ22408@binky.Central.Sun.COM> References: <3EF96AF20489A34296050FBD5C36ECB93BD140@beacon.PSC.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB93BD140@beacon.PSC.process.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Mon, Jul 31, 2006 at 09:16:38AM -0400, Richard Whalen wrote: > The Filexfer draft was never a ftp-like protocol. It was originally a > file access protocol that was missing a text access method. After the > text access method got added it has moved towards becoming a file system > protocol. IMO, publish the parts of the filexfer protocol that are commonly implemented as an Informational document (and then only as Informational and not targetting Standards-Track if it fails to meet general IETF requirements, e.g., I18N). I don't see why a text access method should be required for a Standards-Track filexfer protocol for the Secure Shell protoco, but hey, I'll take an Informational document over no document at all any day. > I feel that the filexfer draft has grown so much that many don't have > the resources to implement the current drafts, hence many implementations > are still a few versions back. Agreed. > I feel that there is a significant need for the technology though and > would like to see a protocol for the transfer of file data over SSH > standardized. Secsh may not be the right place for this. SSH may be > well enough established that people can think of it as a transport and > that the proper protocol can be developed in the applications area. Agreed. The protocol should be reviewed in the apps area, by apps area experts and ADs. And since the protocol borrows from NFSv4 it should also be reviewed by NFSv4 WG participants, at least with respect to the parts of NFSv4 that filexfer does borrow. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 04 11:21:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91UQ-0001MJ-Mr for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 04 Aug 2006 11:21:30 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91UP-0005To-9m for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 04 Aug 2006 11:21:30 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 2BD5363B20C; Fri, 4 Aug 2006 15:16:15 +0000 (UTC) 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 02DC163B13E for ; Fri, 4 Aug 2006 15:16:13 +0000 (UTC) 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 k3RAQi2x091691 for ; Thu, 27 Apr 2006 13:27:09 +0300 (EEST) (envelope-from ni4@ukr.net) Date: Thu, 27 Apr 2006 13:25:37 +0300 From: "Nickolay L." X-Mailer: The Bat! (v3.0.1.33) Professional Reply-To: "Nickolay L." X-Priority: 3 (Normal) Message-ID: <15441853.20060427132537@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: 0.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 <] From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 17 21:32:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDtE0-0000bv-7x for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 17 Aug 2006 21:32:40 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDtDy-0000pv-VG for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 17 Aug 2006 21:32:40 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 43C7863B37D; Fri, 18 Aug 2006 01:32:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 6691563B27F for ; Fri, 18 Aug 2006 01:32:24 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1D541E00C1; Thu, 17 Aug 2006 17:48:41 -0400 (EDT) From: Sam Hartman To: ietf-ssh@netbsd.org Cc: housley@vigilsec.com Subject: Intent to close the ssh working group Date: Thu, 17 Aug 2006 17:48:41 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Based on community feedback it is my intent to close this working group as soon as the publickey-subsystem draft is either approved by the IESG or stalls. Bill has indicated he believes the draft is ready for publication. The mailing list will remain open. If the authors of the URI draft update it to include only the ssh URI, I will accept it as an individual submission after the working group is closed. It can keep the same name. Other ssh drafts may be submitted as individual drafts (draft-authorname-blah-xx.txt). Authors are requested to inform internet-drafts@ietf.org that their individual draft replaces the appropriate draft-ietf-secsh draft. This message should be included in the ID submission to notify the secretariat that I'm approving allowing an individual draft to replace a working group draft. I will not sponsor the filexfer draft for publication as an IETF documents. The authors may talk to the applications or transport area about forming a new working group to do the work; may request that the rfc editor publish an informational document as an independent submission; or drop the drafts. Sam Hartman Security Area Director From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 18 18:00:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECOE-00032s-8Z for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 18:00:30 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GECOC-0007Kk-Vm for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 18:00:30 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id EF51F63B100; Fri, 18 Aug 2006 22:00:15 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id E9EA363B1C0 for ; Fri, 18 Aug 2006 22:00:10 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7IJRvNu027545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2006 15:27:57 -0400 (EDT) Date: Fri, 18 Aug 2006 15:27:57 -0400 From: Jeffrey Hutzelman To: Sam Hartman , ietf-ssh@NetBSD.org cc: housley@vigilsec.com, Jeffrey Hutzelman Subject: Re: Intent to close the ssh working group Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:013tMG10g7e0sqHn5YEVE2RnVFPQJlB39LSDQ8FFM=; 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: 798b2e660f1819ae38035ac1d8d5e3ab On Thursday, August 17, 2006 05:48:41 PM -0400 Sam Hartman wrote: > I will not sponsor the filexfer draft for publication as an IETF > documents. The authors may talk to the applications or transport area > about forming a new working group to do the work; may request that the > rfc editor publish an informational document as an independent > submission; or drop the drafts. For completeness, I'll point out that another possibility would be to find some other AD to sponsor the document as an individual IETF submission. I suspect that the set of people likely to be interested in working on a filesystem access protocol is different than the set where were interested in working on the core ssh protocol. So, it's entirely possible that a BOF on this subject may produce enough interest to form a WG. Personally, I'd very much like to see an actual _file transfer_ protocol that I can run over SSH. Maybe SCP is sufficient for this; I don't know. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 18 19:28:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEDlP-0001sb-A9 for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 19:28:31 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEDlL-0003BL-Vn for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 19:28:31 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4F0E663B3E7; Fri, 18 Aug 2006 23:28:25 +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 34CB363B195 for ; Fri, 18 Aug 2006 23:28:24 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7IM5mfC009540 for ; Fri, 18 Aug 2006 16:05:48 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7IM5lLf006196 for ; Fri, 18 Aug 2006 16:05:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7IM5lwH011500; Fri, 18 Aug 2006 17:05:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7IM5kEJ011499; Fri, 18 Aug 2006 17:05:46 -0500 (CDT) Date: Fri, 18 Aug 2006 17:05:46 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-ssh@NetBSD.org, housley@vigilsec.com Subject: Re: Intent to close the ssh working group Message-ID: <20060818220546.GV10208@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Fri, Aug 18, 2006 at 03:27:57PM -0400, Jeffrey Hutzelman wrote: > For completeness, I'll point out that another possibility would be to find > some other AD to sponsor the document as an individual IETF submission. Well, yes. > I suspect that the set of people likely to be interested in working on a > filesystem access protocol is different than the set where were interested > in working on the core ssh protocol. So, it's entirely possible that a BOF > on this subject may produce enough interest to form a WG. For one item? Note that the security area wouldn't be a very good home for this. The transport area seems more appropriate, particularly for a filesystem protocol. > Personally, I'd very much like to see an actual _file transfer_ protocol > that I can run over SSH. Maybe SCP is sufficient for this; I don't know. SCP is not sufficient. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 18 20:05:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEELZ-0000J0-Jw for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 20:05:53 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEELY-0000pr-Ao for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 20:05:53 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 92BA063B2AE; Sat, 19 Aug 2006 00:05:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id 8248063B2AB for ; Sat, 19 Aug 2006 00:05:39 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7IMNb8C003012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2006 18:23:37 -0400 (EDT) Date: Fri, 18 Aug 2006 18:23:37 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: Sam Hartman , ietf-ssh@NetBSD.org, housley@vigilsec.com, Jeffrey Hutzelman Subject: Re: Intent to close the ssh working group Message-ID: <091B629A324904AB5D52873A@sirius.fac.cs.cmu.edu> In-Reply-To: <20060818220546.GV10208@binky.Central.Sun.COM> References: <20060818220546.GV10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:019r67EmAmMIZCCTOTKTzrgY0w8j198jRjM+l3LD4=; 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: ea4ac80f790299f943f0a53be7e1a21a On Friday, August 18, 2006 05:05:46 PM -0500 Nicolas Williams wrote: >> I suspect that the set of people likely to be interested in working on a >> filesystem access protocol is different than the set where were >> interested in working on the core ssh protocol. So, it's entirely >> possible that a BOF on this subject may produce enough interest to form >> a WG. > > For one item? Note that the security area wouldn't be a very good home > for this. The transport area seems more appropriate, particularly for a > filesystem protocol. It's only one item if you make it huge and monolithic. If, instead, you break it out into a manageable base document and a set of optional extensions, it becomes several items. It also offers the opportunity to take a step back and figure out what the goals and requirements actually are. So far, it seems like they get rehashed with every proposed extension, and it's starting to get hard to tell what the consensus is. About the only thing that's clear to me is that the people working on this project mostly are interested in something like a filesystem, rather than something like a file transfer protocol. I agree the security area is not the right home for this. I'm inclined to think the right home is actually the apps area; I've never understood why NFS was in transport and not apps. Perhaps someone else knows. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 18 21:15:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEFRO-0006MN-Q8 for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 21:15:58 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEFRN-0006X5-Fo for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 18 Aug 2006 21:15:58 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id F375863B2C2; Sat, 19 Aug 2006 01:15:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 110D463B2BB for ; Sat, 19 Aug 2006 01:15:50 +0000 (UTC) Received: from [192.168.0.3] (HELO gt) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with SMTP id 458222; Fri, 18 Aug 2006 19:16:20 -0600 Message-ID: <011901c6c32c$fce71da0$6801a8c0@gt> From: "Jeff P. Van Dyke" To: "Jeffrey Hutzelman" , "Nicolas Williams" Cc: "Sam Hartman" , , References: <20060818220546.GV10208@binky.Central.Sun.COM> <091B629A324904AB5D52873A@sirius.fac.cs.cmu.edu> Subject: Re: Intent to close the ssh working group Date: Fri, 18 Aug 2006 19:15:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c > On Friday, August 18, 2006 05:05:46 PM -0500 Nicolas Williams > wrote: > >>> I suspect that the set of people likely to be interested in working on a >>> filesystem access protocol is different than the set where were >>> interested in working on the core ssh protocol. So, it's entirely >>> possible that a BOF on this subject may produce enough interest to form >>> a WG. >> >> For one item? Note that the security area wouldn't be a very good home >> for this. The transport area seems more appropriate, particularly for a >> filesystem protocol. > > It's only one item if you make it huge and monolithic. If, instead, you > break it out into a manageable base document and a set of optional > extensions, it becomes several items. It also offers the opportunity to > take a step back and figure out what the goals and requirements actually > are. So far, it seems like they get rehashed with every proposed > extension, and it's starting to get hard to tell what the consensus is. > About the only thing that's clear to me is that the people working on this > project mostly are interested in something like a filesystem, rather than > something like a file transfer protocol. > > I agree the security area is not the right home for this. I'm inclined to > think the right home is actually the apps area; I've never understood why > NFS was in transport and not apps. Perhaps someone else knows. > > -- Jeff Some have argued that the recent additions to the SFTP draft make it more like a filesystem. I would argue the basic implementation that most folks are using (SFTP v3) is more like a filesystem than a file transfer protocol. In particular, there is no put or get in SFTP v3 - instead it has open, close, read, write, etc. I'm not sure where the work or WG belongs, but I would like to see the SFTP draft completed (acknowledging that is has always been more filesystem than file transfer) - even if we had to strip it down to core functionality and push off some of the newer stuff to extensions. I'd also be very supportive of a file transfer draft too. However, I'm not sure there is enough consensus to make this happen :-) I think having a documented standard for transferring files using more of a put and get mechanism would address many of the real world issues (e.g. performance and logging) that SFTP has. --Jeff V. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Aug 19 12:47:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GETys-0008IJ-Qp for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 19 Aug 2006 12:47:30 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GETyr-0002Xj-DN for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 19 Aug 2006 12:47:30 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 343FB63B38C; Sat, 19 Aug 2006 16:47:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 2F71363B150 for ; Sat, 19 Aug 2006 16:47:11 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 459356; Sat, 19 Aug 2006 10:47:41 -0600 Message-ID: <44E74362.8000803@vandyke.com> Date: Sat, 19 Aug 2006 10:59:14 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Jeff P. Van Dyke" CC: Jeffrey Hutzelman , Nicolas Williams , Sam Hartman , ietf-ssh@NetBSD.org, housley@vigilsec.com Subject: Re: Intent to close the ssh working group References: <20060818220546.GV10208@binky.Central.Sun.COM> <091B629A324904AB5D52873A@sirius.fac.cs.cmu.edu> <011901c6c32c$fce71da0$6801a8c0@gt> In-Reply-To: <011901c6c32c$fce71da0$6801a8c0@gt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Jeff P. Van Dyke wrote: >> On Friday, August 18, 2006 05:05:46 PM -0500 Nicolas Williams >> wrote: >> >>>> I suspect that the set of people likely to be interested in working >>>> on a >>>> filesystem access protocol is different than the set where were >>>> interested in working on the core ssh protocol. So, it's entirely >>>> possible that a BOF on this subject may produce enough interest to >>>> form >>>> a WG. >>> >>> For one item? Note that the security area wouldn't be a very good home >>> for this. The transport area seems more appropriate, particularly for a >>> filesystem protocol. >> >> It's only one item if you make it huge and monolithic. If, instead, >> you break it out into a manageable base document and a set of optional >> extensions, it becomes several items. It also offers the opportunity >> to take a step back and figure out what the goals and requirements >> actually are. So far, it seems like they get rehashed with every >> proposed extension, and it's starting to get hard to tell what the >> consensus is. About the only thing that's clear to me is that the >> people working on this project mostly are interested in something like >> a filesystem, rather than something like a file transfer protocol. >> >> I agree the security area is not the right home for this. I'm >> inclined to think the right home is actually the apps area; I've never >> understood why NFS was in transport and not apps. Perhaps someone >> else knows. >> >> -- Jeff > > Some have argued that the recent additions to the SFTP draft make it more > like a filesystem. > > I would argue the basic implementation that most folks are using (SFTP v3) > is more like a filesystem than a file transfer protocol. In particular, > there is no put or get in SFTP v3 - instead it has open, close, read, > write, etc. > > I'm not sure where the work or WG belongs, but I would like to see the SFTP > draft completed (acknowledging that is has always been more filesystem than > file transfer) - even if we had to strip it down to core functionality and > push off some of the newer stuff to extensions. > > I'd also be very supportive of a file transfer draft too. However, I'm not > sure there is enough consensus to make this happen :-) I think having a > documented standard for transferring files using more of a put and get > mechanism would address many of the real world issues (e.g. performance and > logging) that SFTP has. > > --Jeff V. I agree with both the Jeffs. I would like to see SFTP, the file system protocol, finished. I would also like to see a 'file transfer' protocol, be it an separate document describing an extension to the SFTP or a completely independent protocol (which could range any where from a document describing how use SSH as a transport for FTP to an entirely new protocol.) I believe moving to an area where we might have more people interested could help this work, and help us to determine what we need to do in order to produce a draft which has enough consensus behind it to get published. I don't think the current draft meets that criteria. I think stepping back and defining our goals and producing several documents instead of one monolith would help immensely. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Aug 27 06:11:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHHcE-00026U-Rc for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 27 Aug 2006 06:11:43 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHHcB-000825-IP for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 27 Aug 2006 06:11:42 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 83A1663B38D; Sun, 27 Aug 2006 10:11:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mail.netbsd.org (Postfix) with ESMTP id 6B9D263B21A for ; Sun, 27 Aug 2006 10:11:25 +0000 (UTC) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4N00MADET8J6@szxga03-in.huawei.com> for ietf-ssh@netbsd.org; Sun, 27 Aug 2006 16:41:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4N00LIEET8ED@szxga03-in.huawei.com> for ietf-ssh@netbsd.org; Sun, 27 Aug 2006 16:41:32 +0800 (CST) Received: from [127.0.0.1] ([10.18.18.211]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4N00JCPEIHUG@szxml03-in.huawei.com> for ietf-ssh@netbsd.org; Sun, 27 Aug 2006 16:35:07 +0800 (CST) Date: Sun, 27 Aug 2006 14:00:57 +0530 From: jimmy Subject: query on ssh transport packet To: ietf-ssh@netbsd.org Message-id: <44F15841.4010601@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, Is it possible to have a transport layer packet contain >1 upper layer packets? For eg: Transport_Packet.data { connection.packet{ type = SSH_MSG_CHANNEL_DATA string data } connection.packet{ type = SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 channel_id ... } } The reverse situation where 1 upper layer packet spans >1 transport packet is not permitted, so i just wanted know of this case. Thanks, jimmy -- Endless Loop: n.,see Loop, Endless. Loop Endless: n.,see Endless Loop. -Anonymous From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Aug 27 08:38:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHJto-0007uz-MS for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 27 Aug 2006 08:38:00 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHJtn-0001hj-Dy for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 27 Aug 2006 08:38:00 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 5555763B213; Sun, 27 Aug 2006 12:37:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id 7B0F363B102 for ; Sun, 27 Aug 2006 12:37:45 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 03D9D200A1AA; Sun, 27 Aug 2006 12:39:22 +0200 (CEST) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20244-01-92; Sun, 27 Aug 2006 12:39:07 +0200 (CEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id C4637200A1A6; Sun, 27 Aug 2006 12:39:07 +0200 (CEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.4+Sun/8.13.4) with ESMTP id k7RAd6Qu014133; Sun, 27 Aug 2006 12:39:06 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id k7RAcwvm014130; Sun, 27 Aug 2006 12:38:58 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: jimmy Cc: ietf-ssh@netbsd.org Subject: Re: query on ssh transport packet References: <44F15841.4010601@huawei.com> Content-type: text/plain; charset=iso-8859-1 From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 27 Aug 2006 12:38:56 +0200 In-Reply-To: <44F15841.4010601@huawei.com> Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 jimmy writes: > Is it possible to have a transport layer packet contain >1 upper layer > packets? No. /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Aug 27 23:20:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHXg0-0008By-8O for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 27 Aug 2006 23:20:40 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHXfy-00028P-V0 for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 27 Aug 2006 23:20:40 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id B5DBE63B467; Mon, 28 Aug 2006 03:20:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id D5B0E63B257 for ; Mon, 28 Aug 2006 03:20:20 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E1562E00C0; Sun, 27 Aug 2006 23:20:29 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: AD Review for draft-ietf-secsh-publickey-subsystem From: Sam Hartman Message-Id: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> Date: Sun, 27 Aug 2006 23:20:29 -0400 (EDT) Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi. I have reviewed the publickey subsystem draft for publication and have the following comments The working group must come to consensus on resolution for these comments and a new draft reflecting that consensus should be uploaded. As has previously been noted there is not a lot of energy left in the working group. In the interest of coming to some sort of closure one way or another, thes comments must be addressed by October 31, 2006 or the document will be withdrawn from publication. 1) There is no definition of the public key algorithms or the public key blobs. Please clearly reference what the contents of the public key blob should be. 2) The abstract cannot contain references. There needs to be a terminology section with the standard RFC 2119 language if you are going to use 2119 keywords. id-nits (check http://tools.ietf.org/wg/secsh ) claims there are missing references. 3) What check must a server apply for the from hosts? Is that an IP address/reverse DNS check? Is the server expected to use cryptographic information when available (host keys)? Presumably not, but you should say this. 4) 64-chars seems too short for local names. A DNS domain name can be much longer than that. 5) Please use RFC 3066 for language tags. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Aug 28 16:55:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHo8u-0001H4-VX for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 28 Aug 2006 16:55:36 -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 1GHmJ7-0000D8-Ea for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 28 Aug 2006 14:58:01 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHm47-0004ps-AC for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 28 Aug 2006 14:42:36 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 4D46B63B4D2; Mon, 28 Aug 2006 18:42:23 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 3CB3163B4D1 for ; Mon, 28 Aug 2006 18:42:22 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7SGh8gQ018654 for ; Mon, 28 Aug 2006 09:43:08 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7SGh2YP027338 for ; Mon, 28 Aug 2006 10:43:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7SGgQat015521; Mon, 28 Aug 2006 11:42:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7SGgGAd015520; Mon, 28 Aug 2006 11:42:16 -0500 (CDT) Date: Mon, 28 Aug 2006 11:42:16 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-ssh@NetBSD.org Subject: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <20060828164216.GJ10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -2.5 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Sun, Aug 27, 2006 at 11:20:29PM -0400, Sam Hartman wrote: - I18N, L10N: > 5) Please use RFC 3066 for language tags. And the proper reference for UTF-8 is not RFC2279 either but RFC3629/STD0063. Also, since SSHv2 itself performs language negotiation, and since Unicode provides codepoints for indicating the language of a string/sub-string, why does this protocol need a slot for RFC3066 language tags at all? I think you should just remove/deprecate the language tag field and rely on the language negotiation performed by SSHv2. - I'd rather the "mandatory" attribute of attributes be named "critical"... - Are attributes like "x11" and so on booleans? Or does their presence/absence act as a boolean? And if so, what kind of values do they take on? - Clients need to know what kind of environment "command-override" values will be evaluated in. Should there be a request by which a client can ask for a description of said environment, and a status reply by which a server can list attributes of the environment like the OS it runs, OS release, values of certain environment variables, etc... I would think so, something like: string "status" uint32 SSH_PUBLICKEY_ENVIRONMENT uint32 env_count string envvar_name string envvar_value along with some pre-defined environment variable names, like OS, OSREL, ARCH, PATH etc... - How should the command-override and subsystem attributes interact? - How much of the execution environment of command-overrides be specified here? - An attribute is needed to set environment variables for the environment where the command/shell/subsystem is executed. Cheers, Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 06:19:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI0gL-0000Lq-Uk for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 06:18:57 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI0dI-00033x-3z for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 06:15:52 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 2DB6963B274; Tue, 29 Aug 2006 10:15:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 44D5663B13C for ; Tue, 29 Aug 2006 10:15:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id DDA5410545E; Tue, 29 Aug 2006 10:14:29 +0200 (CEST) Message-ID: <44F3F8E1.3030008@siliconcircus.com> Date: Tue, 29 Aug 2006 10:20:49 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sam Hartman CC: ietf-ssh@netbsd.org Subject: Re: AD Review for draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> In-Reply-To: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Sam Hartman wrote: > > 1) There is no definition of the public key algorithms or the public > key blobs. Please clearly reference what the contents of the public key > blob should be. Opening of section 2: "The format of public-key blobs are detailed in the SSH Transport Protocol document [2].". Is this not sufficient, or had you overlooked it? > 2) The abstract cannot contain references. I've moved the paragraph starting "This protocol is intended to be used from the Secure Shell Connection Protocol.." out of the Abstract and into Introduction. > There needs to be a > terminology section with the standard RFC 2119 language if you are > going to use 2119 keywords. Added betweek Introduction and Overview. > id-nits (check > http://tools.ietf.org/wg/secsh ) claims there are missing > references. Fixed by updating to the RFCs which obsoleted the referenced RFCs. > 3) What check must a server apply for the from hosts? Is that an IP > address/reverse DNS check? Is the server expected to use > cryptographic information when available (host keys)? Presumably not, but you should say this. That's really platform-dependent. I've added the following text: "The server should use whatever method is appropriate for its platform to identify the host - e.g. for IP-based networks, checking the IP address or performing a reverse DNS lookup." > 4) 64-chars seems too short for local names. A DNS domain name can be > much longer than that. This was discussed previously in the WG. The requirement is that way because the requirement in ssh-arch is the same: "In this protocol, all algorithm and method identifiers MUST be printable US-ASCII, non-empty strings no longer than 64 characters. Names MUST be case-sensitive." > 5) Please use RFC 3066 for language tags. As above, updated to 1766. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 07:39:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1vp-00050T-Fx for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 07:39:01 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI1vn-0002E0-1Q for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 07:39:01 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 59A5063B3B6; Tue, 29 Aug 2006 11:38:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 0D45D63B3A6 for ; Tue, 29 Aug 2006 11:38:54 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 669E710424F; Tue, 29 Aug 2006 10:14:32 +0200 (CEST) Message-ID: <44F3F8E4.1050900@siliconcircus.com> Date: Tue, 29 Aug 2006 10:20:52 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nicolas Williams CC: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> In-Reply-To: <20060828164216.GJ10208@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Nicolas Williams wrote: > On Sun, Aug 27, 2006 at 11:20:29PM -0400, Sam Hartman wrote: > > - I18N, L10N: > >> 5) Please use RFC 3066 for language tags. > > And the proper reference for UTF-8 is not RFC2279 either but > RFC3629/STD0063. Have updated this. > > Also, since SSHv2 itself performs language negotiation, and since > Unicode provides codepoints for indicating the language of a > string/sub-string, why does this protocol need a slot for RFC3066 > language tags at all? > I think you should just remove/deprecate the language tag field and > rely on the language negotiation performed by SSHv2. SSH2 negotiation negotiates a list of the languages to be used (or doesn't - that negotiation is optional). The tags specify which of those languages is in use. (In much the same way that the language tag for, say, SSH_MSG_DISCONNECT does.) As for why we don't use Unicode language indicators - no idea, but I'd prefer to keep this consistent with all the messages in the other RFCs which also don't. > - I'd rather the "mandatory" attribute of attributes be named > "critical"... This would change a sentence like "If the server does not implement a mandatory attribute, it MUST fail the add.." to "If the server does not implement a critical attribute, it MUST fail the add..". The first seems preferable to me. > - Are attributes like "x11" and so on booleans? Or does their > presence/absence act as a boolean? And if so, what kind of values do > they take on? Their presence/absence act as boolean. As for their values, "The attribute-value field SHOULD be empty for this attribute.". > - Clients need to know what kind of environment "command-override" > values will be evaluated in. Under what circumstances? > Should there be a request by which a > client can ask for a description of said environment, and a status > reply by which a server can list attributes of the environment like > the OS it runs, OS release, values of certain environment variables, > etc... I would think so, something like: > > string "status" > uint32 SSH_PUBLICKEY_ENVIRONMENT > uint32 env_count > string envvar_name > string envvar_value > > along with some pre-defined environment variable names, like OS, > OSREL, ARCH, PATH etc... Even if it's desirable, I think it's too late for this kind of change. > - How should the command-override and subsystem attributes interact? command-override overrides SSH_MSG_CHANNEL_REQUESTs with "shell" or "exec". subsystem places limits on SSH_MSG_CHANNEL_REQUESTs with "subsystem". They're independent. > - How much of the execution environment of command-overrides be > specified here? If I've understood the question correctly: the only thing it specifies is the path. I don't really know when you'd need to specify more? > - An attribute is needed to set environment variables for the > environment where the command/shell/subsystem is executed. Why? Again, I think it's too late for this kind of substantive change. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 11:42:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5jF-0005bP-IF for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 11:42:17 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI5jE-0004ql-A2 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 11:42:17 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 7CE0E63B128; Tue, 29 Aug 2006 15:42:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id C9A9E63B125 for ; Tue, 29 Aug 2006 15:42:02 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4A450E00C0; Tue, 29 Aug 2006 11:42:01 -0400 (EDT) From: Sam Hartman To: Jon Bright Cc: ietf-ssh@netbsd.org Subject: Re: AD Review for draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <44F3F8E1.3030008@siliconcircus.com> Date: Tue, 29 Aug 2006 11:42:01 -0400 In-Reply-To: <44F3F8E1.3030008@siliconcircus.com> (Jon Bright's message of "Tue, 29 Aug 2006 10:20:49 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 >>>>> "Jon" == Jon Bright writes: Jon> Sam Hartman wrote: >> 1) There is no definition of the public key algorithms or the >> public key blobs. Please clearly reference what the contents of >> the public key blob should be. Jon> Opening of section 2: "The format of public-key blobs are Jon> detailed in the SSH Transport Protocol document [2].". Is Jon> this not sufficient, or had you overlooked it? I had overlooked it, but could you please include a reference to the specific section. Your other changes seem fine. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 11:45:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5lu-0008RU-IU for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 11:45:02 -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 1GI5lu-0005hu-H0 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 11:45:02 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GI5ls-00063i-Ai for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 11:45:02 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id B8E3663B17C; Tue, 29 Aug 2006 15:44:51 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id E528163B125 for ; Tue, 29 Aug 2006 15:44:50 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6D8B1E00C0; Tue, 29 Aug 2006 11:44:53 -0400 (EDT) From: Sam Hartman To: Jon Bright Cc: Nicolas Williams , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> Date: Tue, 29 Aug 2006 11:44:53 -0400 In-Reply-To: <44F3F8E4.1050900@siliconcircus.com> (Jon Bright's message of "Tue, 29 Aug 2006 10:20:52 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -2.5 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >>>>> "Jon" == Jon Bright writes: >> - I'd rather the "mandatory" attribute of attributes be named >> "critical"... Jon> This would change a sentence like "If the server does not Jon> implement a mandatory attribute, it MUST fail the add.." to Jon> "If the server does not implement a critical attribute, it Jon> MUST fail the add..". The first seems preferable to me. My personal opinion is that critical is far preferable to mandatory in a security protocol. The usage you seem to be objecting to is quite common in PKIX documents and is becoming more common in Kerberos documents and other things throughout the security area. I didn't make the common as an AD because I thought it a bit late, but I support this change as an individual. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 13:50:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7jh-0003qX-9L for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 13:50:53 -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 1GI7ew-0007M4-V6 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 13:45:58 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GI7cn-0008Re-Lr for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 13:43:48 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id DA51963B14C; Tue, 29 Aug 2006 17:43:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by mail.netbsd.org (Postfix) with ESMTP id DBC6463B118 for ; Tue, 29 Aug 2006 17:43:37 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7TGE8j7002374 for ; Tue, 29 Aug 2006 09:14:08 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7TGDvQW018806 for ; Tue, 29 Aug 2006 10:14:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7TGDRlY026010; Tue, 29 Aug 2006 11:13:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7TGDRKh026009; Tue, 29 Aug 2006 11:13:27 -0500 (CDT) Date: Tue, 29 Aug 2006 11:13:26 -0500 From: Nicolas Williams To: Jon Bright Cc: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <20060829161326.GX10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F3F8E4.1050900@siliconcircus.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -2.5 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 On Tue, Aug 29, 2006 at 10:20:52AM +0200, Jon Bright wrote: > Nicolas Williams wrote: > > SSH2 negotiation negotiates a list of the languages to be used (or > doesn't - that negotiation is optional). The tags specify which of > those languages is in use. (In much the same way that the language tag > for, say, SSH_MSG_DISCONNECT does.) > > As for why we don't use Unicode language indicators - no idea, but I'd > prefer to keep this consistent with all the messages in the other RFCs > which also don't. I misremembered how the rest of SSHv2 handles this -- usually a language tag field does accompany localized strings in the protocol. I think that's kind of useless (what do I do with that tag, client-side?). But you are following the pattern from the rest of the SSHv2 protocol family, so I withdraw my comment re: language tag fields. > > - I'd rather the "mandatory" attribute of attributes be named > > "critical"... > > This would change a sentence like "If the server does not implement a > mandatory attribute, it MUST fail the add.." to "If the server does not > implement a critical attribute, it MUST fail the add..". The first > seems preferable to me. The word "critical" is very commonly taken to mean what this doc means by "mandatory" and there is no chance of confusing it with RFC2119 terminology. I very strongly encourage this change. I think it makes the spec much more readable. > > - Are attributes like "x11" and so on booleans? Or does their > > presence/absence act as a boolean? And if so, what kind of values do > > they take on? > > Their presence/absence act as boolean. As for their values, "The > attribute-value field SHOULD be empty for this attribute.". Thanks. > > - Clients need to know what kind of environment "command-override" > > values will be evaluated in. > > Under what circumstances? So users (and even programs, I suppose) can properly construct command-override values. I don't feel strongly about this though. > > - How should the command-override and subsystem attributes interact? > > command-override overrides SSH_MSG_CHANNEL_REQUESTs with "shell" or > "exec". subsystem places limits on SSH_MSG_CHANNEL_REQUESTs with > "subsystem". They're independent. OpenSSH does wrap subsystems with forced_commands, thus my question. > > - How much of the execution environment of command-overrides be > > specified here? > > If I've understood the question correctly: the only thing it specifies > is the path. I don't really know when you'd need to specify more? Are there environment variables that are set, etc...? Or are such details out of scope for your document? > > - An attribute is needed to set environment variables for the > > environment where the command/shell/subsystem is executed. > > Why? Again, I think it's too late for this kind of substantive change. Because the facility you patterned this after (right? OpenSSH?) has a way to associate environment variables with public keys. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 13:53:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7lt-00061o-6s for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 13:53:09 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI7lr-0008Ro-U5 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 13:53:09 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 7A96963B20D; Tue, 29 Aug 2006 17:52:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id ABCA863B15E for ; Tue, 29 Aug 2006 17:52:54 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 524094; Tue, 29 Aug 2006 09:53:33 -0600 Message-ID: <44F462D5.3040908@vandyke.com> Date: Tue, 29 Aug 2006 09:52:53 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sam Hartman CC: Jon Bright , Nicolas Williams , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Sam Hartman wrote: >>>>>> "Jon" == Jon Bright writes: > >> - I'd rather the "mandatory" attribute of attributes be named > >> "critical"... > > Jon> This would change a sentence like "If the server does not > Jon> implement a mandatory attribute, it MUST fail the add.." to > Jon> "If the server does not implement a critical attribute, it > Jon> MUST fail the add..". The first seems preferable to me. > > My personal opinion is that critical is far preferable to mandatory in > a security protocol. The usage you seem to be objecting to is quite > common in PKIX documents and is becoming more common in Kerberos > documents and other things throughout the security area. > > I didn't make the common as an AD because I thought it a bit late, but > I support this change as an individual. I don't have any objection one way or the other-- however, if "critical" is becoming part of the 'standard writing language' for security documents, we should probably adopt that standard. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 29 17:13:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAq8-0000gp-4A for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 17:09:44 -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 1GIAOZ-0003il-JM for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 16:41:15 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIALp-0005eV-2X for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 29 Aug 2006 16:38:26 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id A67CF63B567; Tue, 29 Aug 2006 20:38:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id 5C0DE63B2B7 for ; Tue, 29 Aug 2006 20:38:12 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7TIY4oX021714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 14:34:05 -0400 (EDT) Date: Tue, 29 Aug 2006 14:34:04 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Jon Bright cc: Nicolas Williams , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: In-Reply-To: References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> Originator-Info: login-token=Mulberry:01SxUWFLV9i4iXYI6VfpNGg+KHTT/SSY+4ikR5gZU=; 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: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Tuesday, August 29, 2006 11:44:53 AM -0400 Sam Hartman wrote: >>>>>> "Jon" == Jon Bright writes: > >> - I'd rather the "mandatory" attribute of attributes be named > >> "critical"... > > Jon> This would change a sentence like "If the server does not > Jon> implement a mandatory attribute, it MUST fail the add.." to > Jon> "If the server does not implement a critical attribute, it > Jon> MUST fail the add..". The first seems preferable to me. > > My personal opinion is that critical is far preferable to mandatory in > a security protocol. The usage you seem to be objecting to is quite > common in PKIX documents and is becoming more common in Kerberos > documents and other things throughout the security area. I agree. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 02:20:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIJRT-0006dX-Ee for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 02:20:51 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIJRS-0000s6-5E for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 02:20:51 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 489F663B5C6; Wed, 30 Aug 2006 06:20:34 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 15DE763B5C5 for ; Wed, 30 Aug 2006 06:20:32 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 952E7105EDD; Wed, 30 Aug 2006 08:20:30 +0200 (CEST) Message-ID: <44F52E9A.1040203@siliconcircus.com> Date: Wed, 30 Aug 2006 08:22:18 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sam Hartman CC: Nicolas Williams , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Sam Hartman wrote: >>>>>> "Jon" == Jon Bright writes: > >> - I'd rather the "mandatory" attribute of attributes be named > >> "critical"... > > Jon> This would change a sentence like "If the server does not > Jon> implement a mandatory attribute, it MUST fail the add.." to > Jon> "If the server does not implement a critical attribute, it > Jon> MUST fail the add..". The first seems preferable to me. > > My personal opinion is that critical is far preferable to mandatory in > a security protocol. The usage you seem to be objecting to is quite > common in PKIX documents and is becoming more common in Kerberos > documents and other things throughout the security area. > > I didn't make the common as an AD because I thought it a bit late, but > I support this change as an individual. OK, since everyone seems to want this, I'll change the wording to "critical". I'm still confused about why this is an improvement, though. In normal English usage, "critical" has several meanings. One of these is "indispensible, essential" (and having looked at several dictionaries, that's usually the meaning right before the definitions involving nuclear physics begin). "Mandatory" seems to have only the meaning wanted in this document. Far be it from me to be (ahem) critical of the security area's documents, but doesn't "mandatory" express the required meaning in a way more easily understood by the uninitiated reader? Maybe I'm missing something... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 05:37:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIMVu-0005Eu-8U for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 05:37:38 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIMVt-0001sR-0S for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 05:37:38 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 2D62D63B17E; Wed, 30 Aug 2006 09:37:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mail.netbsd.org (Postfix) with ESMTP id 6F95863B148 for ; Wed, 30 Aug 2006 09:37:23 +0000 (UTC) Received: by py-out-1112.google.com with SMTP id n25so205224pyg for ; Wed, 30 Aug 2006 02:37:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VoyhSS0/QoSqEF7INlomRwQ2POOBuBSt0dYauL7oSjXBmwsWRScUM7K6ZK2wWYsmgtFTJlLpuT9Lz4a1ZSxm4Bh7bos7V0hVWuUouCQskTCAeUrjNPhdfgx6oU6BSmggGoMkvnNvckIaJDjiMJk8HrzlGtL588cX1NEoZV8NcLk= Received: by 10.35.21.9 with SMTP id y9mr612915pyi; Wed, 30 Aug 2006 02:37:22 -0700 (PDT) Received: by 10.35.84.12 with HTTP; Wed, 30 Aug 2006 02:37:22 -0700 (PDT) Message-ID: <97ac95820608300237g707e3ffav7d0a6489d138dc4a@mail.gmail.com> Date: Wed, 30 Aug 2006 11:37:22 +0200 From: "stefano landucci" To: ietf-ssh@netbsd.org Subject: first message MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi, I subscribe in this mailing list for receive more information about SSH. I'm a italian student that search information about Elliptic curves, more just if SSH support this type of cryptography. If you have document on this subject and you can give me the address when I can read on it I' w very happy. Sorry for bad English and sorry if the question don't answer to the mailing list goal. Thank's Stefano Landucci From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 06:52:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GINgS-0007SM-Cn for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 06:52:36 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GINgR-0002d9-4A for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 06:52:36 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id F155163B1DA; Wed, 30 Aug 2006 10:52:31 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 3113363B134 for ; Wed, 30 Aug 2006 10:52:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 085233DA71; Wed, 30 Aug 2006 12:52:17 +0200 (CEST) Message-ID: <44F56E49.3020706@siliconcircus.com> Date: Wed, 30 Aug 2006 12:54:01 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nicolas Williams CC: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> In-Reply-To: <20060829161326.GX10208@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Nicolas Williams wrote: > >>> - An attribute is needed to set environment variables for the >>> environment where the command/shell/subsystem is executed. >> Why? Again, I think it's too late for this kind of substantive change. > > Because the facility you patterned this after (right? OpenSSH?) has a > way to associate environment variables with public keys. I didn't write the original version of this draft, I've just been shepherding it since it became a WG working item. It'd be nice to document how OpenSSH does this, but I think it's too late to make this the job of this draft. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 06:52:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GINgb-0007Sz-U8 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 06:52:45 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GINga-0002iB-HS for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 06:52:45 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 6444D63B308; Wed, 30 Aug 2006 10:52:39 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 2E15F63B28E for ; Wed, 30 Aug 2006 10:52:28 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id AE66B10A130; Wed, 30 Aug 2006 12:52:27 +0200 (CEST) Message-ID: <44F56E52.4040905@siliconcircus.com> Date: Wed, 30 Aug 2006 12:54:10 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: internet-drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-07.txt Content-Type: multipart/mixed; boundary="------------080902040306010200080203" Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b93f0dc9ddba0752e520e7aa9e82b4eb This is a multi-part message in MIME format. --------------080902040306010200080203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached draft-ietf-secsh-publickey-subsystem-07.txt Thanks, -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------080902040306010200080203 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-07.txt" Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Intended status: Informational B. McClure Expires: March 3, 2007 VanDyke Software J. Bright Silicon Circus August 30, 2006 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 3, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Galbraith, et al. Expires March 3, 2007 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem August 2006 Abstract Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Galbraith, et al. Expires March 3, 2007 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem August 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 6 3.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 6 3.2. Requests and Responses . . . . . . . . . . . . . . . . . . 7 3.3. The Status Message . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 7 3.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 8 4. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 9 4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9 4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12 4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12 4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15 6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16 6.3. Request Names . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Response Names . . . . . . . . . . . . . . . . . . . . . . 16 6.5. Attribute Names . . . . . . . . . . . . . . . . . . . . . 16 6.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 17 6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17 6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17 6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Galbraith, et al. Expires March 3, 2007 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem August 2006 1. Introduction Secure Shell is a protocol for secure remote login and other secure network services over an insecure network. Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the Secure Shell transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the Secure Shell architecture [1] and Secure Shell connection [4] documents. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires March 3, 2007 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem August 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [5]. Galbraith, et al. Expires March 3, 2007 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem August 2006 3. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove, and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in section 6.6, "Public Key Algorithms" of the SSH Transport Protocol document [2]. 3.1. Opening the Public-Key Subsystem The public-key subsystem is started by a client sending an SSH_MSG_CHANNEL_REQUEST over an existing session's channel. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" Client implementations SHOULD reject this request; it is normally sent only by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the public-key subsystem (for example, because the user authenticated with a restricted public key). It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires March 3, 2007 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem August 2006 3.2. Requests and Responses All public-key subsystem requests and responses are sent in the following form: uint32 length string name ... request/response specific data follows The length field describes the length of the name field and of the request/response-specific data, but does not include the length of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. The version packet, as well as all requests and responses described in Section 4, are a description of the 'name' field and the data part of the packet. 3.3. The Status Message A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-3629] string language tag [RFC-3066] A status message MUST be sent for any unrecognized packets, and the request SHOULD NOT close the subsystem. 3.3.1. Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 Galbraith, et al. Expires March 3, 2007 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem August 2006 If a request completed successfully, the server MUST send the status code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as implied by their names. 3.4. The Version Packet Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number This document describes version 2 of the protocol. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Note that, normally, status messages are only sent by the server (in response to requests from the client). This is the only occasion on which the client sends a status message. Both sides MUST wait to receive this version before continuing. The "version" packet MUST NOT be sent again after this initial exchange. The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent in response to any other request. Galbraith, et al. Expires March 3, 2007 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem August 2006 4. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and listattributes. 4.1. Adding a Public Key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists, but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED. Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a critical attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a critical attribute, mere storage of the attribute is not sufficient -- rather, the server must understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [7]. Galbraith, et al. Expires March 3, 2007 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem August 2006 The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be critical. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specify the language for that attribute [6]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment with its language attribute. This attribute SHOULD NOT be critical. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorization checks the server may perform). This attribute SHOULD be critical. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be critical. If the value is empty, no subsystems may be started. If the "subsystem" attribute is not specified, no restrictions are placed on which subsystems may be started when authenticated using this key. "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "exec" Galbraith, et al. Expires March 3, 2007 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem August 2006 "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be critical. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorization purposes, the authorization attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. The server should use whatever method is appropriate for its platform to identify the host - e.g. for IP-based networks, checking the IP address or performing a reverse DNS lookup. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except those to hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be critical. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, except for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be critical. In addition to the attributes specified by the client, the server MAY provide a method for administrators to enforce certain attributes compulsorily. Galbraith, et al. Expires March 3, 2007 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem August 2006 4.2. Removing a Public Key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 4.3. Listing Public Keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 4.4. Listing Server Capabilities If the client wishes to know which key attributes the server supports, it sends: string "listattributes" The server will respond with zero or more of the following responses: string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the Galbraith, et al. Expires March 3, 2007 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem August 2006 attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. An example of use of the "compulsory" attribute would be a server with a configuration file specifying that the user is not permitted shell access. Given this, the server would return the "shell" attribute, with "compulsory" marked true. Whatever attributes the user subsequently asked the server to apply to their key, the server would also apply the "shell" attribute, rendering it impossible for the user to use a shell. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires March 3, 2007 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem August 2006 5. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorize keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires March 3, 2007 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem August 2006 6. IANA Considerations This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments. 6.1. Registrations Consistent with Section 7 of [1], this document makes the following registration: The subsystem name "publickey". 6.2. Names In the following sections, the values for the namespaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections. 6.2.1. Conventions for Names All names registered by the IANA in the following sections MUST be printable US-ASCII strings, and MUST NOT contain the characters at- sign ("@"), comma (","), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign in them. Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceeding the at-sign is the name. The format of the part preceding the at-sign is not specified, however these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), or whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified Internet domain name [9] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [8] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [8]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). Galbraith, et al. Expires March 3, 2007 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem August 2006 6.2.2. Future Assignments of Names Requests for assignments of new Names MUST be done through the IETF Consensus method as described in [10]. 6.3. Request Names The following table lists the initial assignments of Request names. Request Name ------------- version add remove list listattributes 6.4. Response Names The following table lists the initial assignments of Response names. Response Name -------------- version status publickey attribute 6.5. Attribute Names Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Attribute names. Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward Galbraith, et al. Expires March 3, 2007 [Page 16] Internet-Draft Secure Shell Public-Key Subsystem August 2006 6.6. Status Codes The status code is a byte value, describing the status of a request. 6.6.1. Conventions Status responses have status codes in the range 0 to 255. These numbers are allocated as follows. Of these, the range 192 to 255 is reserved for use by local, private extensions. 6.6.2. Initial Assignments The following table identifies the initial assignments of the status code values. Status code Value Reference ------------ ----- --------- SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 6.6.3. Future Assignments Requests for assignments of new message numbers in the range of 0 to 191 MUST be done through the Standards Action method as described in [10]. The IANA will not control the message numbers range of 192 through 255. This range will be left for private use. Galbraith, et al. Expires March 3, 2007 [Page 17] Internet-Draft Secure Shell Public-Key Subsystem August 2006 7. References 7.1. Normative References [1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 7.2. Informative References [8] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [9] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Galbraith, et al. Expires March 3, 2007 [Page 18] Internet-Draft Secure Shell Public-Key Subsystem August 2006 Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: jpv@vandyke.com Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 Email: jon@siliconcircus.com Galbraith, et al. Expires March 3, 2007 [Page 19] Internet-Draft Secure Shell Public-Key Subsystem August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Galbraith, et al. Expires March 3, 2007 [Page 20] --------------080902040306010200080203-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 12:23:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISqC-0002vI-GE for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 12:23:00 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISqB-0004cU-75 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 12:23:00 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id A1F3763B606; Wed, 30 Aug 2006 16:22:46 +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 D018663B326 for ; Wed, 30 Aug 2006 16:22:45 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UFCWqH024046 for ; Wed, 30 Aug 2006 08:12:32 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UFCV8d022313 for ; Wed, 30 Aug 2006 09:12:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UFCVdj026740; Wed, 30 Aug 2006 10:12:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UFCRJT026739; Wed, 30 Aug 2006 10:12:27 -0500 (CDT) Date: Wed, 30 Aug 2006 10:12:27 -0500 From: Nicolas Williams To: Jon Bright Cc: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <20060830151227.GI10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F56E49.3020706@siliconcircus.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Wed, Aug 30, 2006 at 12:54:01PM +0200, Jon Bright wrote: > Nicolas Williams wrote: > > > >>>- An attribute is needed to set environment variables for the > >>> environment where the command/shell/subsystem is executed. > >>Why? Again, I think it's too late for this kind of substantive change. > > > >Because the facility you patterned this after (right? OpenSSH?) has a > >way to associate environment variables with public keys. > > I didn't write the original version of this draft, I've just been > shepherding it since it became a WG working item. It'd be nice to > document how OpenSSH does this, but I think it's too late to make this > the job of this draft. But then OpenSSH can't implement this protocol without changing its existing behaviour. Therefore I think the fair thing to do would be to either allow the 'command-override' command to override subsystem commands also. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 12:38:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT5A-00014J-3w for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 12:38:28 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIT57-0008Mg-QS for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 12:38:28 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 98F4663B61F; Wed, 30 Aug 2006 16:37:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id 8784263B61B for ; Wed, 30 Aug 2006 16:37:58 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7UGbtWV027359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 12:37:56 -0400 (EDT) Date: Wed, 30 Aug 2006 12:37:55 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Jon Bright cc: Sam Hartman , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <047AE86D94A4EC1676864B25@sirius.fac.cs.cmu.edu> In-Reply-To: <20060830151227.GI10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> <20060830151227.GI10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01hLjM0O4gQUTQA0RRtzb8PxsqA/sL7EXxLfo1ujg=; 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: 21c69d3cfc2dd19218717dbe1d974352 On Wednesday, August 30, 2006 10:12:27 AM -0500 Nicolas Williams wrote: > On Wed, Aug 30, 2006 at 12:54:01PM +0200, Jon Bright wrote: >> Nicolas Williams wrote: >> > >> >>> - An attribute is needed to set environment variables for the >> >>> environment where the command/shell/subsystem is executed. >> >> Why? Again, I think it's too late for this kind of substantive >> >> change. >> > >> > Because the facility you patterned this after (right? OpenSSH?) has a >> > way to associate environment variables with public keys. >> >> I didn't write the original version of this draft, I've just been >> shepherding it since it became a WG working item. It'd be nice to >> document how OpenSSH does this, but I think it's too late to make this >> the job of this draft. > > But then OpenSSH can't implement this protocol without changing its > existing behaviour. > Therefore I think the fair thing to do would be to either allow the > 'command-override' command to override subsystem commands also I don't think so. Subsystems are not the same as shells. A subsystem name is essentially a protocol constant used to request a particular service; it is not a command. It's appropriate to limit what subsystems may be used, but not to replace a subsystem with a connection to a random program that does not speak the protocol defined for that subsystem. I understand that this is the current OpenSSH behavior, but I believe that behavior is problematic, and that defining a useful, interoperable behavior is more important than being consistent with OpenSSH. OpenSSH _can_ implement this protocol without eliminating its existing behavior and without breaking backward-compatibility, by introducing a new keyword which has the effect specified for command-override. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 13:28:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrE-0003jo-0s for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:28:08 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITet-000883-MG for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:15:24 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 8D37163B642; Wed, 30 Aug 2006 17:15:21 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id 84D6D63B63C for ; Wed, 30 Aug 2006 17:15:20 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7UHFFNt028577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 13:15:16 -0400 (EDT) Date: Wed, 30 Aug 2006 13:15:15 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: Jon Bright , Sam Hartman , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <04AF3DFF31D3BC8A98F98867@sirius.fac.cs.cmu.edu> In-Reply-To: <20060830164950.GQ10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> <20060830151227.GI10208@binky.Central.Sun.COM> <047AE86D94A4EC1676864B25@sirius.fac.cs.cmu.edu> <20060830164950.GQ10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01LO9Y+5ZXzW94OtB8X22IasNhjyazI9GZZIZgYm8=; 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: 8b30eb7682a596edff707698f4a80f7d On Wednesday, August 30, 2006 11:50:08 AM -0500 Nicolas Williams wrote: > On Wed, Aug 30, 2006 at 12:37:55PM -0400, Jeffrey Hutzelman wrote: >> > Therefore I think the fair thing to do would be to either allow the >> > 'command-override' command to override subsystem commands also >> >> I don't think so. >> >> Subsystems are not the same as shells. A subsystem name is essentially >> a protocol constant used to request a particular service; it is not a >> command. It's appropriate to limit what subsystems may be used, but not >> to replace a subsystem with a connection to a random program that does >> not speak the protocol defined for that subsystem. > > But the command-override wouldn't fail to speak the subsystem's > protocol -- typically it would be a wrapper for another program that > does speak that protocol. No, because that's not how openssh works. OpenSSH's "command" option specifies a command that is used for _any_ connection authenticated by that key. That command is used for any new shell or subsystem, and it does not get to know what the user requested. That makes it kind of hard to know what protocol the client wants to speak, let alone implement it. >> OpenSSH _can_ implement this protocol without eliminating its existing >> behavior and without breaking backward-compatibility, by introducing a >> new keyword which has the effect specified for command-override. > > But you couldn't faithfully list pre-existing authorized_keys file > entries. Sure you could, using an attribute like "command@openssh.org". But I would not object to adding an OPTIONAL attribute with similar semantics, to allow OpenSSH to express current behavior. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 13:28:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrg-0004Ro-TE for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:28:36 -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 1GISfX-0002BK-Co for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 12:11:59 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GISQE-0002vZ-0v for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 11:56:12 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1C0C763B5F9; Wed, 30 Aug 2006 15:55:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id 0661B63B5FD for ; Wed, 30 Aug 2006 15:55:54 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7UFtkSd025744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 11:55:52 -0400 (EDT) Date: Wed, 30 Aug 2006 11:55:46 -0400 From: Jeffrey Hutzelman To: Jon Bright , Sam Hartman cc: Nicolas Williams , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: In-Reply-To: <44F52E9A.1040203@siliconcircus.com> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <44F52E9A.1040203@siliconcircus.com> Originator-Info: login-token=Mulberry:01NPFE/Z5ZuXGAPLx+Z290bMtjeyi7Jb2hZnJianE=; 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: -2.6 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Wednesday, August 30, 2006 08:22:18 AM +0200 Jon Bright wrote: > Sam Hartman wrote: >>>>>>> "Jon" == Jon Bright writes: >> >> - I'd rather the "mandatory" attribute of attributes be named >> >> "critical"... >> >> Jon> This would change a sentence like "If the server does not >> Jon> implement a mandatory attribute, it MUST fail the add.." to >> Jon> "If the server does not implement a critical attribute, it >> Jon> MUST fail the add..". The first seems preferable to me. >> >> My personal opinion is that critical is far preferable to mandatory in >> a security protocol. The usage you seem to be objecting to is quite >> common in PKIX documents and is becoming more common in Kerberos >> documents and other things throughout the security area. >> >> I didn't make the common as an AD because I thought it a bit late, but >> I support this change as an individual. > > OK, since everyone seems to want this, I'll change the wording to > "critical". I'm still confused about why this is an improvement, though. > > In normal English usage, "critical" has several meanings. One of these > is "indispensible, essential" (and having looked at several dictionaries, > that's usually the meaning right before the definitions involving nuclear > physics begin). "Mandatory" seems to have only the meaning wanted in > this document. The distinction here is subtle but important. The word "mandatory" usually describes things that MUST be implemented. The word "critical", in a security context, is used to describe things that need not be implemented, but which have the effect of producing incorrect behavior if blindly ignored. Such features/extensions/whatever must be rejected if they are seen by an implementation which doesn't understand them. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 13:31:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITud-0005tr-T5 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:31:39 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITuc-00042y-IH for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:31:39 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 274D863B649; Wed, 30 Aug 2006 17:31:36 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 2B89463B643 for ; Wed, 30 Aug 2006 17:31:35 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 530574; Wed, 30 Aug 2006 11:32:14 -0600 Message-ID: <44F5CB75.5080102@vandyke.com> Date: Wed, 30 Aug 2006 11:31:33 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Nicolas Williams , Jon Bright , Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> <20060830151227.GI10208@binky.Central.Sun.COM> <047AE86D94A4EC1676864B25@sirius.fac.cs.cmu.edu> <20060830164950.GQ10208@binky.Central.Sun.COM> <04AF3DFF31D3BC8A98F98867@sirius.fac.cs.cmu.edu> In-Reply-To: <04AF3DFF31D3BC8A98F98867@sirius.fac.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Jeffrey Hutzelman wrote: > > > On Wednesday, August 30, 2006 11:50:08 AM -0500 Nicolas Williams > wrote: > >> On Wed, Aug 30, 2006 at 12:37:55PM -0400, Jeffrey Hutzelman wrote: >>> > Therefore I think the fair thing to do would be to either allow the >>> > 'command-override' command to override subsystem commands also >>> >>> I don't think so. >>> >>> Subsystems are not the same as shells. A subsystem name is essentially >>> a protocol constant used to request a particular service; it is not a >>> command. It's appropriate to limit what subsystems may be used, but not >>> to replace a subsystem with a connection to a random program that does >>> not speak the protocol defined for that subsystem. >> >> But the command-override wouldn't fail to speak the subsystem's >> protocol -- typically it would be a wrapper for another program that >> does speak that protocol. > > No, because that's not how openssh works. OpenSSH's "command" option > specifies a command that is used for _any_ connection authenticated by > that key. That command is used for any new shell or subsystem, and it > does not get to know what the user requested. That makes it kind of > hard to know what protocol the client wants to speak, let alone > implement it. > >>> OpenSSH _can_ implement this protocol without eliminating its existing >>> behavior and without breaking backward-compatibility, by introducing a >>> new keyword which has the effect specified for command-override. >> >> But you couldn't faithfully list pre-existing authorized_keys file >> entries. > > Sure you could, using an attribute like "command@openssh.org". > But I would not object to adding an OPTIONAL attribute with similar > semantics, to allow OpenSSH to express current behavior. It doesn't seem inappropriate to use "@openssh.org" to express an openssh compatibility option. In the normal course of events, I wouldn't be opposed to adding a standard attribute to the draft, but I'm worried that something like that would require us to redo last-call? And given the deadline we are operating under, I suspect this is not a winning option. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 30 13:53:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUFp-00070u-ID for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:53:33 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIUFm-0001ts-6x for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 30 Aug 2006 13:53:33 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 97FCE63B190; Wed, 30 Aug 2006 17:53:27 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by mail.netbsd.org (Postfix) with ESMTP id 35A4663B123 for ; Wed, 30 Aug 2006 17:53:26 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UHrPNu020947 for ; Wed, 30 Aug 2006 10:53:25 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UHrEQE004704 for ; Wed, 30 Aug 2006 11:53:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UHqx4Q026930; Wed, 30 Aug 2006 12:52:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UHqxLI026929; Wed, 30 Aug 2006 12:52:59 -0500 (CDT) Date: Wed, 30 Aug 2006 12:52:59 -0500 From: Nicolas Williams To: Joseph Galbraith Cc: Jeffrey Hutzelman , Jon Bright , Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <20060830175258.GW10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> <20060830151227.GI10208@binky.Central.Sun.COM> <047AE86D94A4EC1676864B25@sirius.fac.cs.cmu.edu> <20060830164950.GQ10208@binky.Central.Sun.COM> <04AF3DFF31D3BC8A98F98867@sirius.fac.cs.cmu.edu> <44F5CB75.5080102@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F5CB75.5080102@vandyke.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Wed, Aug 30, 2006 at 11:31:33AM -0600, Joseph Galbraith wrote: > It doesn't seem inappropriate to use "@openssh.org" to express > an openssh compatibility option. > > In the normal course of events, I wouldn't be opposed to adding > a standard attribute to the draft, but I'm worried that something > like that would require us to redo last-call? And given the > deadline we are operating under, I suspect this is not a winning > option. If I decide that I'm happy with vendor-specific command-override alternatives then I won't ask you to change the draft and I'll withdraw my comment. However, what I requested was simple enough: add text saying that servers MAY apply command-overrides to subsystems. I think this MAY should be non-controversial -- there is already way too much that is left unstated about the environment in which command- overrides are executed. For example, OpenSSH sets a number of SSH_* environment variables in the environment of forced commands to convery information about the connection and/or channel in the context of which the command is being executed. And you would not want to specify such things here. But by constraining command-overrides so they do not apply to subsystems you create a problem. The MAY and command-override@openssh.com solutions both address the problem, but I think the former is easier to understand for users of this protocol than the latter. Users already have to know quite a bit about the environment on the server, such as paths to the command-override programs, and may even want to write their own, in which case they have to know even more about the environment. So asking users to know whether command-override applies to subsystems seems reasonable, but asking them to know that command-override@openssh.com (or do you expect the client to learn this?) means the same seems like too much. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 06:04:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIjP6-0002Jv-Sr for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 06:04:08 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIjP3-0005Je-Ih for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 06:04:08 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 3781963B1F8; Thu, 31 Aug 2006 10:03:52 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 95DDD63B127 for ; Thu, 31 Aug 2006 10:03:50 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UHXHd9021240 for ; Wed, 30 Aug 2006 11:33:17 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UHX6lr025656 for ; Wed, 30 Aug 2006 11:33:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UHWjO1026889; Wed, 30 Aug 2006 12:32:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UHWi96026888; Wed, 30 Aug 2006 12:32:44 -0500 (CDT) Date: Wed, 30 Aug 2006 12:32:44 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Jon Bright , Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <20060830173244.GS10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> <20060830151227.GI10208@binky.Central.Sun.COM> <047AE86D94A4EC1676864B25@sirius.fac.cs.cmu.edu> <20060830164950.GQ10208@binky.Central.Sun.COM> <04AF3DFF31D3BC8A98F98867@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04AF3DFF31D3BC8A98F98867@sirius.fac.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: 97adf591118a232206bdb5a27b217034 On Wed, Aug 30, 2006 at 01:15:15PM -0400, Jeffrey Hutzelman wrote: > On Wednesday, August 30, 2006 11:50:08 AM -0500 Nicolas Williams > wrote: > >But the command-override wouldn't fail to speak the subsystem's > >protocol -- typically it would be a wrapper for another program that > >does speak that protocol. > > No, because that's not how openssh works. OpenSSH's "command" option > specifies a command that is used for _any_ connection authenticated by that > key. That command is used for any new shell or subsystem, and it does not > get to know what the user requested. That makes it kind of hard to know > what protocol the client wants to speak, let alone implement it. OpenSSH sets environment variables like SSH_ORIGINAL_COMMAND, so forced commands can find out that, gee, this is for the sftp subsystem, say. > >>OpenSSH _can_ implement this protocol without eliminating its existing > >>behavior and without breaking backward-compatibility, by introducing a > >>new keyword which has the effect specified for command-override. > > > >But you couldn't faithfully list pre-existing authorized_keys file > >entries. > > Sure you could, using an attribute like "command@openssh.org". > But I would not object to adding an OPTIONAL attribute with similar > semantics, to allow OpenSSH to express current behavior. True, you could do that, and you might argue that that is the better thing to do, because then a presumably savvy client would know about this subtle semantic difference. I have to decide whether this makes my concern go away. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 10:33:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInc8-0003BZ-4o for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 10:33:52 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInc6-0003QD-S9 for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 10:33:52 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 8414263B248; Thu, 31 Aug 2006 14:33:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 913A463B1F4 for ; Thu, 31 Aug 2006 14:33:38 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 533701; Thu, 31 Aug 2006 08:34:19 -0600 Message-ID: <44F6F341.10704@vandyke.com> Date: Thu, 31 Aug 2006 08:33:37 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sam Hartman CC: ietf-ssh@netbsd.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Sam Hartman wrote: > > I'd like to draw your attention to a particularly annoying part of RFC 4254: > > This last form executes a predefined subsystem. It is expected that > these will include a general file transfer mechanism, and possibly > other features. Implementations may also allow configuring more such > mechanisms. As the user's shell is usually used to execute the > subsystem, it is advisable for the subsystem protocol to have a > "magic cookie" at the beginning of the protocol transaction to > distinguish it from arbitrary output generated by shell > initialization scripts, etc. This spurious output from the shell may > be filtered out either at the server or at the client. > > In order to guarantee interoperability, your subsystem needs to be > able to filter out leading garbage and clients MUST do so. > > The spec doesn't currently do this. I think the version packet can serve this purpose. Something like this inserted in the version packet description: Implementations SHOULD use the first 15 bytes of the version packet as a "magice cookie" (see RFC 4252, Section Xxx) to avoid processing spurious output from the users shell. These bytes will always be: 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E (Someone should check my hand encoding of the version packet-- note that the actual version packet has an additional four bytes which are the actual version number-- I didn't include this in the magic cookie because it isn't constant.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 10:38:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInh4-00046X-Ah for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 10:38:58 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInh2-0003ZD-Ud for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 10:38:58 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 1161E63B1F4; Thu, 31 Aug 2006 14:38:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 5523863B10C for ; Thu, 31 Aug 2006 14:38:54 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 533718; Thu, 31 Aug 2006 08:39:35 -0600 Message-ID: <44F6F47C.4060602@vandyke.com> Date: Thu, 31 Aug 2006 08:38:52 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jon Bright CC: Sam Hartman , ietf-ssh@netbsd.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage References: <44F6F350.1030008@siliconcircus.com> In-Reply-To: <44F6F350.1030008@siliconcircus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Jon Bright wrote: > Sam Hartman wrote: >> >> In order to guarantee interoperability, your subsystem needs to be >> able to filter out leading garbage and clients MUST do so. >> >> The spec doesn't currently do this. > > I'll admit to having overlooked that. Would > > 00 00 00 07 76 65 72 73 69 6f 6e > > ('string "version"' in SSHish), which both sides send on start, be > sufficient as a magic number? > > If so, I can just add a sentence referring to the garbage filtering and > pointing out that some garbage may appear before this byte string. Hah... we crossed in the mail :-) Actually, having thought about it a little more, I suspect that in practice the byte string 00 00 00 (the first three valid protocol bytes) would be sufficient to filter out 99.99999% of all shell output. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 11:22:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoNO-0003y8-Iy for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 11:22:42 -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 1GInm3-0003sg-Lp for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 10:44:07 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GInaT-0001Aw-6o for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 10:32:14 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id CE68363B293; Thu, 31 Aug 2006 14:32:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 180A563B10C for ; Thu, 31 Aug 2006 14:32:00 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 262DB109BE5; Thu, 31 Aug 2006 16:31:54 +0200 (CEST) Message-ID: <44F6F350.1030008@siliconcircus.com> Date: Thu, 31 Aug 2006 16:33:52 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sam Hartman CC: ietf-ssh@netbsd.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -2.6 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Sam Hartman wrote: > > In order to guarantee interoperability, your subsystem needs to be > able to filter out leading garbage and clients MUST do so. > > The spec doesn't currently do this. I'll admit to having overlooked that. Would 00 00 00 07 76 65 72 73 69 6f 6e ('string "version"' in SSHish), which both sides send on start, be sufficient as a magic number? If so, I can just add a sentence referring to the garbage filtering and pointing out that some garbage may appear before this byte string. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 12:48:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpiQ-0003sl-Ab for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 12:48:30 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpiL-0000OJ-Vn for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 12:48:30 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 0C56163B31D; Thu, 31 Aug 2006 16:48:13 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 1F19D63B2D4 for ; Thu, 31 Aug 2006 16:48:11 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7VEuhf0026360 for ; Thu, 31 Aug 2006 07:56:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7VEuWvQ010626 for ; Thu, 31 Aug 2006 08:56:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7VEu7cH027930; Thu, 31 Aug 2006 09:56:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7VEu7rI027929; Thu, 31 Aug 2006 09:56:07 -0500 (CDT) Date: Thu, 31 Aug 2006 09:56:07 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-ssh@NetBSD.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage Message-ID: <20060831145606.GH27432@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, Aug 31, 2006 at 08:52:03AM -0400, Sam Hartman wrote: > I'd like to draw your attention to a particularly annoying part of RFC 4254: > > This last form executes a predefined subsystem. It is expected that > these will include a general file transfer mechanism, and possibly > other features. Implementations may also allow configuring more such > mechanisms. As the user's shell is usually used to execute the > subsystem, it is advisable for the subsystem protocol to have a > "magic cookie" at the beginning of the protocol transaction to > distinguish it from arbitrary output generated by shell > initialization scripts, etc. This spurious output from the shell may > be filtered out either at the server or at the client. > > > In order to guarantee interoperability, your subsystem needs to be > able to filter out leading garbage and clients MUST do so. The text you quote says "advisable" and "may." It is typically a misconfiguration to have user shells output anything when there is no tty, and sysadmins bloody well know this -- users don't though, which is why it's advisable to have this protocol feature, but it certainly isn't REQUIRED by the text you quote. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 13:32:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqP0-00033M-Fx for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 13:32:30 -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 1GIm7n-0002YH-7Q for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 08:58:27 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIm1d-0006mF-6I for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 08:52:06 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 3C32863B16A; Thu, 31 Aug 2006 12:51:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 8D22663B12D for ; Thu, 31 Aug 2006 12:51:57 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9C6DBE00C0; Thu, 31 Aug 2006 08:52:03 -0400 (EDT) From: Sam Hartman To: ietf-ssh@netbsd.org Subject: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage Date: Thu, 31 Aug 2006 08:52:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -2.5 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 I'd like to draw your attention to a particularly annoying part of RFC 4254: This last form executes a predefined subsystem. It is expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish it from arbitrary output generated by shell initialization scripts, etc. This spurious output from the shell may be filtered out either at the server or at the client. In order to guarantee interoperability, your subsystem needs to be able to filter out leading garbage and clients MUST do so. The spec doesn't currently do this. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 13:39:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqVR-0007Sl-Sn for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 13:39:09 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqVQ-0005KV-J2 for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 13:39:09 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 17A4A63B159; Thu, 31 Aug 2006 17:39:05 +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 0423263B10B for ; Thu, 31 Aug 2006 17:39:03 +0000 (UTC) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UGo9kM009366 for ; Wed, 30 Aug 2006 10:50:09 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UGo8Dm005865 for ; Wed, 30 Aug 2006 10:50:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UGo8vc026854; Wed, 30 Aug 2006 11:50:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UGo8tD026853; Wed, 30 Aug 2006 11:50:08 -0500 (CDT) Date: Wed, 30 Aug 2006 11:50:08 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Jon Bright , Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Other comments on draft-ietf-secsh-publickey-subsystem Message-ID: <20060830164950.GQ10208@binky.Central.Sun.COM> References: <20060828032029.E1562E00C0@carter-zimmerman.mit.edu> <20060828164216.GJ10208@binky.Central.Sun.COM> <44F3F8E4.1050900@siliconcircus.com> <20060829161326.GX10208@binky.Central.Sun.COM> <44F56E49.3020706@siliconcircus.com> <20060830151227.GI10208@binky.Central.Sun.COM> <047AE86D94A4EC1676864B25@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <047AE86D94A4EC1676864B25@sirius.fac.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: 8b30eb7682a596edff707698f4a80f7d On Wed, Aug 30, 2006 at 12:37:55PM -0400, Jeffrey Hutzelman wrote: > >Therefore I think the fair thing to do would be to either allow the > >'command-override' command to override subsystem commands also > > I don't think so. > > Subsystems are not the same as shells. A subsystem name is essentially a > protocol constant used to request a particular service; it is not a > command. It's appropriate to limit what subsystems may be used, but not to > replace a subsystem with a connection to a random program that does not > speak the protocol defined for that subsystem. But the command-override wouldn't fail to speak the subsystem's protocol -- typically it would be a wrapper for another program that does speak that protocol. Yes, this is very much implementation-specific as other implementations and even future versions of OpenSSH (for all I know) might use other means to implement subsystems, such as dynamically loaded plug-ins. But all I ask is that the OpenSSH behaviour be allowed. > I understand that this is > the current OpenSSH behavior, but I believe that behavior is problematic, > and that defining a useful, interoperable behavior is more important than > being consistent with OpenSSH. I agree, but this does not preclude allowing the OpenSSH behaviour explicitly. > OpenSSH _can_ implement this protocol without eliminating its existing > behavior and without breaking backward-compatibility, by introducing a new > keyword which has the effect specified for command-override. But you couldn't faithfully list pre-existing authorized_keys file entries. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 16:01:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsj3-0001EI-2t for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 16:01:21 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsj1-00053b-Ox for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 16:01:21 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 7FBE163B1BC; Thu, 31 Aug 2006 20:01:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 5D27363B12A for ; Thu, 31 Aug 2006 20:01:06 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7VK15Q2022893 for ; Thu, 31 Aug 2006 13:01:05 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7VK10tO005042 for ; Thu, 31 Aug 2006 14:01:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7VK04FY029227; Thu, 31 Aug 2006 15:00:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7VK04ds029226; Thu, 31 Aug 2006 15:00:04 -0500 (CDT) Date: Thu, 31 Aug 2006 15:00:04 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-ssh@netbsd.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage Message-ID: <20060831200003.GF29007@binky.Central.Sun.COM> References: <20060831145606.GH27432@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Thu, Aug 31, 2006 at 03:39:25PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Thu, Aug 31, 2006 at 08:52:03AM -0400, Sam Hartman > Nicolas> wrote: > >> I'd like to draw your attention to a particularly annoying part > >> of RFC 4254: > >> > >> This last form executes a predefined subsystem. It is expected > >> that these will include a general file transfer mechanism, and > >> possibly other features. Implementations may also allow > >> configuring more such mechanisms. As the user's shell is > >> usually used to execute the subsystem, it is advisable for the > >> subsystem protocol to have a "magic cookie" at the beginning of > >> the protocol transaction to distinguish it from arbitrary > >> output generated by shell initialization scripts, etc. This > >> spurious output from the shell may be filtered out either at > >> the server or at the client. > >> > >> > >> In order to guarantee interoperability, your subsystem needs to > >> be able to filter out leading garbage and clients MUST do so. > > Nicolas> The text you quote says "advisable" and "may." > > Yes. The server MAY spew random garbage. So, the client MUST deal > with it. Again, "it is advisable for the subsystem protocol to have a "magic cookie" ..." That is, there's no requirement for a magic cookie. And there is no RFC2119 'MAY' about user shells spewing garbage. That said, I believe the answer that the version packet is like such a magic cookie should suffice, no? Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 17:35:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIuC3-00062E-Jr for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 17:35:23 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIuBz-0007xj-85 for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 17:35:23 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 9F21A63B280; Thu, 31 Aug 2006 21:35:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id A6F8863B27B for ; Thu, 31 Aug 2006 21:35:15 +0000 (UTC) Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7VLZ9aW017217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Aug 2006 17:35:09 -0400 (EDT) Date: Thu, 31 Aug 2006 17:35:09 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Sam Hartman cc: ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage Message-ID: <36DBC02E6897BE8EF3B9467A@sirius.fac.cs.cmu.edu> In-Reply-To: <20060831200003.GF29007@binky.Central.Sun.COM> References: <20060831145606.GH27432@binky.Central.Sun.COM> <20060831200003.GF29007@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01ejw3PeSkrLHGh6++rbpnrBGubmgBcLDnsWWisLw=; 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: 21c69d3cfc2dd19218717dbe1d974352 On Thursday, August 31, 2006 03:00:04 PM -0500 Nicolas Williams wrote: > On Thu, Aug 31, 2006 at 03:39:25PM -0400, Sam Hartman wrote: >> >>>>> "Nicolas" == Nicolas Williams writes: >> >> Nicolas> On Thu, Aug 31, 2006 at 08:52:03AM -0400, Sam Hartman >> Nicolas> wrote: >> >> I'd like to draw your attention to a particularly annoying part >> >> of RFC 4254: >> >> >> >> This last form executes a predefined subsystem. It is expected >> >> that these will include a general file transfer mechanism, and >> >> possibly other features. Implementations may also allow >> >> configuring more such mechanisms. As the user's shell is >> >> usually used to execute the subsystem, it is advisable for the >> >> subsystem protocol to have a "magic cookie" at the beginning of >> >> the protocol transaction to distinguish it from arbitrary >> >> output generated by shell initialization scripts, etc. This >> >> spurious output from the shell may be filtered out either at >> >> the server or at the client. >> >> >> >> >> >> In order to guarantee interoperability, your subsystem needs to >> >> be able to filter out leading garbage and clients MUST do so. >> >> Nicolas> The text you quote says "advisable" and "may." >> >> Yes. The server MAY spew random garbage. So, the client MUST deal >> with it. > > Again, "it is advisable for the subsystem protocol to have a "magic > cookie" ..." > > That is, there's no requirement for a magic cookie. And there is no > RFC2119 'MAY' about user shells spewing garbage. I think this argument is pointless. Since the obvious solution has been proposed (twice, I think), and no one seems to object, what does it matter how strong the requirement is? -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 18:17:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIuqx-0004Fv-Sm for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 18:17:39 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIuqw-0006ds-J3 for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 18:17:39 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id B503863B10A; Thu, 31 Aug 2006 22:17:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 6EFBE63B246 for ; Thu, 31 Aug 2006 22:17:24 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9A444E00C2; Thu, 31 Aug 2006 15:40:48 -0400 (EDT) From: Sam Hartman To: Joseph Galbraith Cc: Jon Bright , ietf-ssh@netbsd.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage References: <44F6F350.1030008@siliconcircus.com> <44F6F47C.4060602@vandyke.com> Date: Thu, 31 Aug 2006 15:40:48 -0400 In-Reply-To: <44F6F47C.4060602@vandyke.com> (Joseph Galbraith's message of "Thu, 31 Aug 2006 08:38:52 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >>>>> "Joseph" == Joseph Galbraith writes: Joseph> Hah... we crossed in the mail :-) Joseph> Actually, having thought about it a little more, I suspect Joseph> that in practice the byte string 00 00 00 (the first three Joseph> valid protocol bytes) would be sufficient to filter out Joseph> 99.99999% of all shell output. This works for me. Searching on the text version does not work as well because I can actually see some program outputting that. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 18:17:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIuqy-0004GC-4O for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 18:17:40 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIuqw-0006eI-NT for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 18:17:40 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id CA02963B26E; Thu, 31 Aug 2006 22:17:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 6E66763B13B for ; Thu, 31 Aug 2006 22:17:24 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 955C5E00C1; Thu, 31 Aug 2006 15:39:25 -0400 (EDT) From: Sam Hartman To: Nicolas Williams Cc: ietf-ssh@netbsd.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage References: <20060831145606.GH27432@binky.Central.Sun.COM> Date: Thu, 31 Aug 2006 15:39:25 -0400 In-Reply-To: <20060831145606.GH27432@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 31 Aug 2006 09:56:07 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Aug 31, 2006 at 08:52:03AM -0400, Sam Hartman Nicolas> wrote: >> I'd like to draw your attention to a particularly annoying part >> of RFC 4254: >> >> This last form executes a predefined subsystem. It is expected >> that these will include a general file transfer mechanism, and >> possibly other features. Implementations may also allow >> configuring more such mechanisms. As the user's shell is >> usually used to execute the subsystem, it is advisable for the >> subsystem protocol to have a "magic cookie" at the beginning of >> the protocol transaction to distinguish it from arbitrary >> output generated by shell initialization scripts, etc. This >> spurious output from the shell may be filtered out either at >> the server or at the client. >> >> >> In order to guarantee interoperability, your subsystem needs to >> be able to filter out leading garbage and clients MUST do so. Nicolas> The text you quote says "advisable" and "may." Yes. The server MAY spew random garbage. So, the client MUST deal with it. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 31 20:41:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIx5i-00071b-0B for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 20:41:02 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIx5d-0000vZ-Mt for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 31 Aug 2006 20:41:01 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 7FD5363B530; Fri, 1 Sep 2006 00:40:45 +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 A01C363B31E for ; Fri, 1 Sep 2006 00:40:44 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7VLinYg025129 for ; Thu, 31 Aug 2006 15:44:49 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7VLih69020977 for ; Thu, 31 Aug 2006 15:44:49 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7VLiNO7023209; Thu, 31 Aug 2006 16:44:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7VLiNwS023208; Thu, 31 Aug 2006 16:44:23 -0500 (CDT) Date: Thu, 31 Aug 2006 16:44:23 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage Message-ID: <20060831214422.GI29007@binky.Central.Sun.COM> References: <20060831145606.GH27432@binky.Central.Sun.COM> <20060831200003.GF29007@binky.Central.Sun.COM> <36DBC02E6897BE8EF3B9467A@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36DBC02E6897BE8EF3B9467A@sirius.fac.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: 68c8cc8a64a9d0402e43b8eee9fc4199 On Thu, Aug 31, 2006 at 05:35:09PM -0400, Jeffrey Hutzelman wrote: > I think this argument is pointless. Since the obvious solution has been > proposed (twice, I think), and no one seems to object, what does it matter > how strong the requirement is? It's practically pointless :) I think no change is required but don't object to the proposed change. I'll shut up now. Nico --