From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 02 01:49:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzpeU-0000Q8-KR for secsh-archive@megatron.ietf.org; Tue, 02 Aug 2005 01:49:22 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00241 for ; Tue, 2 Aug 2005 01:49:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 32B7663B208; Tue, 2 Aug 2005 05:49:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by mail.netbsd.org (Postfix) with SMTP id 5F1E363B1D3 for ; Tue, 2 Aug 2005 05:49:15 +0000 (UTC) Received: (qmail 45202 invoked from network); 2 Aug 2005 05:42:35 -0000 Received: from unknown (HELO MARKETING-SYS) (npsanders@sbcglobal.net@64.168.30.29 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2005 05:42:35 -0000 Reply-To: "Nathan Sanders" From: "Nathan Sanders" To: Subject: Sr Compiler Development Opportunity Date: Mon, 1 Aug 2005 22:45:06 -0700 Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 X-Mailer: m5mailer.com PID{d27996ce-60b2-4b26-a482-5e09df311cac} RI{54b21-9088b} Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Message-Id: <20050802054915.5F1E363B1D3@mail.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Hello- I'm hoping to network with you and find out if you know anyone who you think could be interested in the following opportunity? Sr. Compiler Engineer Position Type: Full-Time Employee Location: San Jose, California (Silicon Valley, USA) Generous Compensation and Stock package -------------------------------------------------------------------- Job Description: You will be responsible for identifying, developing, and delivering critical enhancements to programming models and the compiler tool chain for a new and unique multi-processor architecture. Requirements: Experience with compiler back-end technology In-depth understanding of processor architectures Excellent interpersonal and debugging skills Candidate should be self-motivated and comfortable working in a fast paced, mission-critical engineering environment Valuable Skills: Candidates with previous experience in multi-processor architectures, SIMD architectures and media architectures, as well as familiarity with the GCC source base is a plus. Experience: Minimum 3-5 years of experience M.S. in Computer Science, Computer or Electrical Engineering required PhD in Computer Science, Computer or Electrical Engineering a plus More about the company: Our client develops and licenses innovative computing, microprocessor and semiconductor technologies and related intellectual property. They were Founded in the mid 90's, They are very well known for developing their software-based microprocessors, which deliver a balance of low power consumption, high performance, low cost and small size suited for diverse computing platforms. They also develop advanced power management technologies for controlling leakage and increasing power efficiency in semiconductor and computing devices. Thanks, ------------------------------------------------ Nathan Sanders Founder/Manager Bridgenex LLC Office: 1.800.881.5733 Cell: (408)914.8180 Fax: (408) 246.2246 Email: nathan@bridgenex.com Corporate: www.bridgenex.com :::STAFFING CONLULTANT SERVICES FOR HIGH TECH::: From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 04 07:52:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eHF-0001aq-Mh for secsh-archive@megatron.ietf.org; Thu, 04 Aug 2005 07:52:45 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29271 for ; Thu, 4 Aug 2005 07:52:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 55F6963B14A; Thu, 4 Aug 2005 11:52:39 +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 BD20A63B124 for ; Thu, 4 Aug 2005 11:52:38 +0000 (UTC) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j74Bqc3t017089 for ; Thu, 4 Aug 2005 04:52:38 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j74Bqaf8005337; Thu, 4 Aug 2005 04:52:37 -0700 (PDT) Subject: Secure Shell WG non-meeting summary. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1123156353.611.516.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Thu, 04 Aug 2005 13:52:34 +0200 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit [Resend with corrected address] The secure shell working group did not meet at this IETF. Since the last meeting, the five core drafts were (finally!) approved by the IESG, as was draft-ietf-secsh-auth-kbdint[eract; they are now in the RFC-Editor queue with IANA issues resolved and no external dependencies. In addition, two documents (newmodes and break) have passed WG last call with only typo-level issues and are on their way to AD review. Two more are in WG last call (gsskeyex and publickeyfile) and are near completion. Most of the remaining documents will likely enter WG last call before the Vancouver meeting and given that we've been successfully driving issues to closure on the list I don't anticipate needing to meet in Vancouver. Given that the core drafts are already known to have multiple interoperable implementations and wide adoption, we may wish to keep the group alive to progress the recently approved documents to Draft standard. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 04 08:27:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eox-00037u-RL for secsh-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:27:35 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01214 for ; Thu, 4 Aug 2005 08:27:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3685463B190; Thu, 4 Aug 2005 12:27:33 +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 6E7DB63B14E for ; Thu, 4 Aug 2005 12:27:32 +0000 (UTC) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j74CRW3t017185 for ; Thu, 4 Aug 2005 05:27:32 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j74CRUf8012497; Thu, 4 Aug 2005 05:27:30 -0700 (PDT) Subject: ISMS ("Integrated Security Model for SNMP") considering use of SSH transport. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1123158447.611.557.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Thu, 04 Aug 2005 14:27:27 +0200 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit FYI, it appears that the Integrated Security Model for SNMP working group is seriously considering the use of the Secure Shell protocol as a secure transport.. See draft minutes at: ftp://ftp.netlab.nec.de/pub/isms/IETF63/0-isms-minutes-ietf63.txt the ISMS charter page is at: http://www.ietf.org/html.charters/isms-charter.html - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 04 16:43:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0mYr-00075e-6H for secsh-archive@megatron.ietf.org; Thu, 04 Aug 2005 16:43:29 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08886 for ; Thu, 4 Aug 2005 16:43:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6589063B3CC; Thu, 4 Aug 2005 20:43:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by mail.netbsd.org (Postfix) with ESMTP id 9BFBC63B3CA for ; Thu, 4 Aug 2005 20:43:22 +0000 (UTC) Received: from pc6 (1Cust151.tnt109.lnd4.gbr.da.uu.net [62.188.172.151]) by blaster.systems.pipex.net (Postfix) with SMTP id 98383E0001A3; Thu, 4 Aug 2005 21:43:20 +0100 (BST) Message-ID: <029e01c5992c$9b30bb00$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Bill Sommerfeld" , References: <1123158447.611.557.camel@unknown.hamachi.org> Subject: Re: ISMS ("Integrated Security Model for SNMP") considering use of SSHtransport. Date: Thu, 4 Aug 2005 21:41:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Yes, the isms WG meeting was in favour but of course that has yet to be confirmed on the isms list. If and when it is (and hopefully not just transport but userauth, subsystems and connections), Please Help. My experience of the isms list over the past year has been that it has plenty of security experts (it is, after all, a security WG), in-depth knowledge of TLS but not the same richness for SSH. For example, the current I-D looked at TLS as an exemplar of transport level security; I posted the changes I saw as needed for SSH but the unanswered issues for SSH remain mostly unanswered. So if you want to see SSH being used in this way, and isms decides to go this way, please contribute. I made my mind up that SSH was the right stuff five months ago and am relieved that others do too. Tom Petch isms list member with no official role or standing ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Thursday, August 04, 2005 2:27 PM Subject: ISMS ("Integrated Security Model for SNMP") considering use of SSHtransport. > FYI, it appears that the Integrated Security Model for SNMP working > group is seriously considering the use of the Secure Shell protocol as a > secure transport.. > > See draft minutes at: > > ftp://ftp.netlab.nec.de/pub/isms/IETF63/0-isms-minutes-ietf63.txt > > the ISMS charter page is at: > > http://www.ietf.org/html.charters/isms-charter.html > > - Bill > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 08 17:25:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2F7t-0007uO-27 for secsh-archive@megatron.ietf.org; Mon, 08 Aug 2005 17:25:41 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25745 for ; Mon, 8 Aug 2005 17:25:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6E77563B314; Mon, 8 Aug 2005 21:25:08 +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 9AB6A63B2DA for ; Mon, 8 Aug 2005 21:25:07 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j78LP71d029329 for ; Mon, 8 Aug 2005 14:25:07 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j78LP6lM019304; Mon, 8 Aug 2005 17:25:06 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j78LP60Y029283; Mon, 8 Aug 2005 17:25:06 -0400 (EDT) Subject: Re: Start of WG Last Call on draft-ietf-secsh-gsskeyex-09.txt From: Bill Sommerfeld To: ietf-ssh@NetBSD.org In-Reply-To: <1121465673.212935.485.camel@thunk> References: <1121465673.212935.485.camel@thunk> Content-Type: text/plain Message-Id: <1123536305.29244.6.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 08 Aug 2005 17:25:06 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We've reached the end of the WG last call period. I believe we have consensus to publish draft-ietf-secsh-gsskeyex as a Proposed Standard. JHutz: Please fix the nits I pointed out on July 15th and reissue the draft. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 08 18:00:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FfO-0003Rw-Tv for secsh-archive@megatron.ietf.org; Mon, 08 Aug 2005 18:00:18 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27216 for ; Mon, 8 Aug 2005 18:00:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 486F963B1FB; Mon, 8 Aug 2005 22:00:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id AA2AB63B185 for ; Mon, 8 Aug 2005 22:00:15 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E2D4t-0003lG-7f; Mon, 08 Aug 2005 15:14:27 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'SSH Transport Layer Encryption Modes' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Mon, 08 Aug 2005 15:14:27 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has received a request from the Secure Shell WG to consider the following document: - 'SSH Transport Layer Encryption Modes ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-04.txt From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 08 19:07:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GiQ-0008Ol-Gd for secsh-archive@megatron.ietf.org; Mon, 08 Aug 2005 19:07:31 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00891 for ; Mon, 8 Aug 2005 19:07:27 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7848663B305; Mon, 8 Aug 2005 23:07:26 +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 A7D4E63B25E for ; Mon, 8 Aug 2005 23:07:25 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j78N7Ci8022361; Mon, 8 Aug 2005 16:07:12 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j78N7AlM012435; Mon, 8 Aug 2005 19:07:10 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j78N7Amh000357; Mon, 8 Aug 2005 19:07:10 -0400 (EDT) Subject: draft-ietf-secsh-gsskeyex-09.txt for Proposed Standard From: Bill Sommerfeld To: iesg-secretary@ietf.org, Russ Housley , Sam Hartman Cc: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1123542429.29244.71.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 08 Aug 2005 19:07:10 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit The consensus of the Secure Shell Working group is that draft-ietf-secsh-gsskeyex-09.txt should be published as a Proposed Standard. Checklist from: draft-ietf-proto-wgchair-doc-shepherding-05.txt 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by implementors in the WG; members of the IETF GSSAPI community have come to this WG to review the work. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document is of interest to a subset of the WG and the ssh-using community but that subset is solidly behind it. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Some nits were discovered (references in the abstract and a typo); a -10 version should surface shortly to address them. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) References are split. All referenced ID's are either in the RFC Editor Queue or before the IESG already. 1.ijk) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document describes an extension to the Secure Shell protocol allowing the use of GSSAPI security services for authentication and key exchange. * Working Group Summary There was smooth consensus in the working group to publish this as a Proposed Standard * Protocol Quality The WG chair is aware of multiple interoperable implementations. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 08 20:09:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2HgV-00030Z-Lx for secsh-archive@megatron.ietf.org; Mon, 08 Aug 2005 20:09:35 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04281 for ; Mon, 8 Aug 2005 20:09:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DB81063B25E; Tue, 9 Aug 2005 00:09:29 +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 3C11F63B1CC for ; Tue, 9 Aug 2005 00:09:29 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7909SvU007397 for ; Mon, 8 Aug 2005 18:09:28 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7909SlM024192; Mon, 8 Aug 2005 20:09:28 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7909Sr8000598; Mon, 8 Aug 2005 20:09:28 -0400 (EDT) Subject: Secure Shell WG: what's left? From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1123546167.29244.159.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 08 Aug 2005 20:09:27 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We are decidedly well into the "home stretch". Here's what's left on our plate: draft-ietf-secsh-publickeyfile-08: Informational In WG Last Call. We had an *extended* argument about line termination. everything else seems to be OK. Someone want to come up with consensus text? draft-ietf-secsh-publickey-subsystem-02: standards track. Ready for WG Last Call? draft-ietf-secsh-scp-sftp-ssh-uri-02: standards track. Known issue: needs either (a) a trim to remove scp, or (b) a volunteer to write an (informational) SCP spec. draft-ietf-secsh-x509-02: standards track very new. needs PKI expert review. draft-ietf-secsh-filexfer-09 what can I say but *sigh*. the complexity of this draft seems to be increasing, due largely to differences in philosophy between posix/unix and not-posix/unix filesystems. draft-ietf-secsh-agent-02 (Expired) I'm prepared to write this one off for lack of interest. individual submission would be the way to go if someone has the energy. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 08 21:41:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2J78-0007nZ-Dq for secsh-archive@megatron.ietf.org; Mon, 08 Aug 2005 21:41:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10997 for ; Mon, 8 Aug 2005 21:41:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3C29363B332; Tue, 9 Aug 2005 01:40:53 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 0C25463B32D for ; Tue, 9 Aug 2005 01:40:51 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA05199; Mon, 8 Aug 2005 21:40:51 -0400 (EDT) From: der Mouse Message-Id: <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 8 Aug 2005 21:40:00 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: <1123546167.29244.159.camel@thunk> References: <1123546167.29244.159.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Here's what's left on our plate: > draft-ietf-secsh-agent-02 (Expired) > I'm prepared to write this one off for lack of interest. ...?? Am I really the only implementor who bothers to do agent forwarding?! /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 08 22:37:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Jzw-0002mY-Fa for secsh-archive@megatron.ietf.org; Mon, 08 Aug 2005 22:37:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24000 for ; Mon, 8 Aug 2005 22:37:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1BC4063B33F; Tue, 9 Aug 2005 02:37:45 +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 706B263B335 for ; Tue, 9 Aug 2005 02:37:44 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8F0EAE0049; Mon, 8 Aug 2005 22:06:57 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: AD Review comments on draft-ietf-secsh-gsskeyex From: Sam Hartman Date: Mon, 08 Aug 2005 22:06:57 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list The only thing I notice is that in several places the document refers to key exchange methods defined in section 1. I assume it really means section 2. I particularly noticed this in section 5, 6 and 8. The table in section 6 refers to gssapi userauth not gssapi-with-mic. I'm sending these comments to the WG in the hope that the authors will deal with them. I do not want to block the last call on this issue and believe it is even appropriate to delay these revisions until auth48 if no blocking comments come up during last call or IESG review. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 02:05:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NFA-0005qY-It for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 02:05:44 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05951 for ; Tue, 9 Aug 2005 02:05:42 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7685163B35C; Tue, 9 Aug 2005 06:05:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id AA43663B244 for ; Tue, 9 Aug 2005 06:05:37 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 27F2317E605; Tue, 9 Aug 2005 16:05:36 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 263BE17E604; Tue, 9 Aug 2005 16:05:36 +1000 (EST) Date: Tue, 9 Aug 2005 16:05:35 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 8 Aug 2005, der Mouse wrote: >> Here's what's left on our plate: > >> draft-ietf-secsh-agent-02 (Expired) >> I'm prepared to write this one off for lack of interest. > > ...?? Am I really the only implementor who bothers to do agent > forwarding?! Of course not. Other implementors (inc. OpenSSH and PuTTY) just run a protocol very similar to that used by ssh-1.2.x over a channel. It has been thus in OpenSSH since 1999/2000 IIRC. It makes more sense to just to document this, given its wide deployment and obvious utility. Even if we were to ship a new agent protocol based on the aforementioned draft in OpenSSH tomorrow, it would be several years before is was as widely used as the current one. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 02:33:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NgL-0000OA-6R for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 02:33:49 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14178 for ; Tue, 9 Aug 2005 02:33:46 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 61C3A63B360; Tue, 9 Aug 2005 06:33:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 2AA1463B244 for ; Tue, 9 Aug 2005 06:33:43 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA16472; Tue, 9 Aug 2005 02:33:42 -0400 (EDT) From: der Mouse Message-Id: <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 9 Aug 2005 02:17:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> draft-ietf-secsh-agent-02 (Expired) >>> I'm prepared to write this one off for lack of interest. >> ...?? Am I really the only implementor who bothers to do agent >> forwarding?! > Of course not. Other implementors (inc. OpenSSH and PuTTY) just run > a protocol very similar to that used by ssh-1.2.x over a channel. I see. I guess I tend not to consider undocumented protocols as worth considering. Perhaps it's just me, but I've never been much good at implementing undocumented protocols. > It makes more sense to just to document this, If it's sound, that may be the most sensible thing to do. Out of curiosity, does it suffer from the same bugs as the existing agent draft (notably, assuming that it's running over IP)? > Even if we were to ship a new agent protocol based on the > aforementioned draft in OpenSSH tomorrow, it would be several years > before is was as widely used as the current one. Are we in any hurry? I also can't see any reason an implementation couldn't support both, perhaps with a slight tweak to the more recent draft if, as it implies, the old protocol uses the same channel type string as agent-02. (I already have to use private versions of the requests to make agent forwarding work with connection sharing....) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 06:18:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RBr-0008G0-18 for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 06:18:35 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26440 for ; Tue, 9 Aug 2005 06:18:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3D12763B289; Tue, 9 Aug 2005 10:18:30 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 1EDEA63B234 for ; Tue, 9 Aug 2005 10:18:29 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa16023; 9 Aug 2005 6:18 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX19LipyNJaacG6RD4BTTdoAiY41824d1km4@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j79AIFkU000231 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Aug 2005 06:18:17 -0400 (EDT) Date: Tue, 09 Aug 2005 12:18:15 +0200 From: Jeffrey Hutzelman To: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: AD Review comments on draft-ietf-secsh-gsskeyex Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:01+AxkeWJ02e1EV9z6K4qU6I9+m6R/QN1lgZLeLow=; 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 Content-Transfer-Encoding: 7bit On Monday, August 08, 2005 22:06:57 -0400 Sam Hartman wrote: > The only thing I notice is that in several places the document refers > to key exchange methods defined in section 1. I assume it really > means section 2. I particularly noticed this in section 5, 6 and 8. For some reason those references were were static text instead of XML cross-references, and so didn't change with the document. > The table in section 6 refers to gssapi userauth not gssapi-with-mic. Fixed. > I'm sending these comments to the WG in the hope that the authors will > deal with them. I do not want to block the last call on this issue > and believe it is even appropriate to delay these revisions until > auth48 if no blocking comments come up during last call or IESG > review. I've fixed these issues in my source, along with some nits Bill raised before WG last call. They'll all appear in the next version of the draft (if there is one), and/or in the XML I send to the RFC-Editor. I'll make sure to check these are fixed during auth48. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 06:28:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RLv-0003Xt-2L for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 06:28:59 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26670 for ; Tue, 9 Aug 2005 06:28:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8653363B300; Tue, 9 Aug 2005 10:28:54 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 4E5FC63B234 for ; Tue, 9 Aug 2005 10:28:53 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa16061; 9 Aug 2005 6:27 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX18tBtf8oqoBrbKh7LMrPnZ2QRAy7nFHoUg@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j79AR5Eg000296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Aug 2005 06:27:09 -0400 (EDT) Date: Tue, 09 Aug 2005 12:27:05 +0200 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? Message-ID: In-Reply-To: <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01OmGlMaTJGqWGrB2ybd/VoNHT3FzBlR6n1tOWcOE=; 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 Content-Transfer-Encoding: 7bit On Tuesday, August 09, 2005 02:17:56 -0400 der Mouse wrote: > I see. I guess I tend not to consider undocumented protocols as worth > considering. Perhaps it's just me, but I've never been much good at > implementing undocumented protocols. But figuring out what the protocol is supposed to be is half the fun! Seriously, I'm very interested in seeing an agent protocol documented, preferably one with a well-defined extension mechanism(*). > Out of curiosity, does it suffer from the same bugs as the existing > agent draft (notably, assuming that it's running over IP)? I don't believe so. The existing agent draft contains a lot of stuff about tagging forwarded agent connections at each hop, so you can tell where things came from. That might be interesting, but I don't see it being deployed any time soon. > I also can't see any reason an implementation couldn't support both, > perhaps with a slight tweak to the more recent draft if, as it implies, > the old protocol uses the same channel type string as agent-02. (I > already have to use private versions of the requests to make agent > forwarding work with connection sharing....) In most cases the ssh client doesn't implement the agent protocol; it just forwards it off to some program running on the same machine. From a practical standpoint, I think the best option is to make the protocol backwards-compatible and use the same channel string. Otherwise implementations like OpenSSH end up having to export _two_ ports for talking to the agent, depending on which version of the protocol you want it to speak. I would note that because all the messages are different, it should be possible to support both protocols on the same channel, and the current draft describes how a client can tell whether the agent supports the new protocol. (*) Note that the current agent draft does _not_ have a well-defined extension mechanism, as the mechanism it defines requires sending a message code which does not fit in the 8-bit field defined for the purpose... -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 07:13:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2S3M-0003ly-O3 for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 07:13:52 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28822 for ; Tue, 9 Aug 2005 07:13:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EAE3563B352; Tue, 9 Aug 2005 11:13:49 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id D3A4963B102 for ; Tue, 9 Aug 2005 11:13:48 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa15996; 9 Aug 2005 6:13 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX19A7ic23aVG23UZ0tdFNrqbHk5jmfwPlZQ@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j79ADeVI000225 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Aug 2005 06:13:42 -0400 (EDT) Date: Tue, 09 Aug 2005 12:13:39 +0200 From: Jeffrey Hutzelman To: Bill Sommerfeld cc: ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits on draft-ietf-secsh-gsskeyex-09.txt Message-ID: In-Reply-To: <1121465158.212935.447.camel@thunk> References: <1121465158.212935.447.camel@thunk> Originator-Info: login-token=Mulberry:014CusW0qTIc8sdiTcE6ncyned44ZnXyVNoNrAFqs=; 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 Content-Transfer-Encoding: 7bit On Friday, July 15, 2005 18:05:58 -0400 Bill Sommerfeld wrote: > Going through the manual part of http://www.ietf.org/ID-Checklist.html I > found a few nits: > > Abstract: > There are multiple references in the abstract. These need to be > removed so the abstract can be stand-alone. > > Also, the reference-to-2119 text should not appear in the Abstract. > (Usually it goes in immediately after the Introduction) > > Security Considerations section: > "SSH_MSG_KEXGEE_CONTINUE" looks like a typo. > > You don't need to rev the draft right now as I'm about to start a Last > Call. All of these are now fixed in the source; I'm still working on the issues Sam raised in AD review. These changes will appear in the next version, if we have to do an update in response to IETF last call or IESG comments; otherwise I'll deal with them in auth48. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 08:56:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Tem-0001A7-VE for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 08:56:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04234 for ; Tue, 9 Aug 2005 08:56:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D92D363B14E; Tue, 9 Aug 2005 12:56:32 +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 31BFE63B102 for ; Tue, 9 Aug 2005 12:56:32 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Secure Shell WG: what's left? Date: Tue, 9 Aug 2005 08:57:50 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB91883A8@beacon.PSC.process.com> Thread-Topic: Secure Shell WG: what's left? Thread-Index: AcWcdvVGbINuWZM+QiyBEplz1l3yGQAakS+A From: "Richard Whalen" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=20 > draft-ietf-secsh-filexfer-09 > what can I say but *sigh*. > the complexity of this draft seems to be increasing, > due largely to differences in philosophy between posix/unix and > not-posix/unix filesystems. >=20 I prefer to think of this as adding functionality needed for = interoperability that was ignored in earlier versions of this draft. ---------------------- Richard Whalen Process Software From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 09:03:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2TlG-0003Rw-Pk for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 09:03:19 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04588 for ; Tue, 9 Aug 2005 09:03:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9E9E563B365; Tue, 9 Aug 2005 13:03:14 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 7ACC063B364 for ; Tue, 9 Aug 2005 13:03:13 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA17527; Tue, 9 Aug 2005 09:03:04 -0400 (EDT) From: der Mouse Message-Id: <200508091303.JAA17527@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 9 Aug 2005 09:00:12 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB91883A8@beacon.PSC.process.com> References: <3EF96AF20489A34296050FBD5C36ECB91883A8@beacon.PSC.process.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> draft-ietf-secsh-filexfer-09 >> what can I say but *sigh*. >> the complexity of this draft seems to be increasing, >> due largely to differences in philosophy between posix/unix and >> not-posix/unix filesystems. > I prefer to think of this as adding functionality needed for > interoperability that was ignored in earlier versions of this draft. ...but in the process making it impossible for a moderately large class of systems to support more than ASCII under the protocol as specified at all. (Strictly, they can't support even that much, but can probably get away with pretending.) Not that this is unique to filexfer-09; the core drafts suffer from the same problem. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 09:19:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2U0n-0001ZU-5m for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 09:19:21 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05377 for ; Tue, 9 Aug 2005 09:19:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CC31A63B372; Tue, 9 Aug 2005 13:19:04 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6785363B367 for ; Tue, 9 Aug 2005 13:19:00 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA17593; Tue, 9 Aug 2005 09:18:59 -0400 (EDT) From: der Mouse Message-Id: <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 9 Aug 2005 09:03:30 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Seriously, I'm very interested in seeing an agent protocol > documented, preferably one with a well-defined extension > mechanism(*). I agree, that would be nice. >> Out of curiosity, does it suffer from the same bugs as the existing >> agent draft (notably, assuming that it's running over IP)? > I don't believe so. Then that certainly makes it a stronger contender. > The existing agent draft contains a lot of stuff about tagging > forwarded agent connections at each hop, so you can tell where things > came from. That might be interesting, but I don't see it being > deployed any time soon. I believe my implementation does it correctly according to some version of the draft (probably -01). Does that count as "deployed"? >> I also can't see any reason an implementation couldn't support both, >> perhaps with a slight tweak to the more recent draft if, as it >> implies, the old protocol uses the same channel type string as >> agent-02. > In most cases the ssh client doesn't implement the agent protocol; it > just forwards it off to some program running on the same machine. That may or may not describe my implementation, depending on exactly what you mean by "the ssh client" and "some program". In my case, the client and the agent are implemented in the same executable, but run in different processes. > From a practical standpoint, I think the best option is to make the > protocol backwards-compatible and use the same channel string. > Otherwise implementations like OpenSSH end up having to export _two_ > ports for talking to the agent, depending on which version of the > protocol you want it to speak. Ports? All the implementations I've used (including my own) use AF_LOCAL sockets in /tmp, rather than anything with "ports". That aside, yes, it would mean either two rendezvous points (of whatever kind) or protocols different enough that the implementation can tell which version is in use from the first packet - and in the latter case you might as well use the same strings, as you say. > I would note that because all the messages are different, it should > be possible to support both protocols on the same channel, and the > current draft describes how a client can tell whether the agent > supports the new protocol. Yes...but the method is an ugly kludge, because, as I read it, the messages *aren't* all different; there's a collision between agent-02's REQUEST_VERSION and 1.x please-list-identities. If we're going to do a new agent protocol, I'd like to see that fixed so there's no message number overlap. > (*) Note that the current agent draft does _not_ have a well-defined > extension mechanism, as the mechanism it defines requires sending a > message code which does not fit in the 8-bit field defined for the > purpose... Yes, this definitely needs to be fixed. How can I best help this happen? Should I sit down with the 1.x code and try to glark a spec for its agent forwarding protocol? It seems inefficient for me to do that, as compared to someone who already knows the protocol, but if it'd help I can take a swing at it. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 10:09:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Umv-0006hw-DI for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 10:09:05 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08995 for ; Tue, 9 Aug 2005 10:09:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5A0FE63B36A; Tue, 9 Aug 2005 14:09:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 0CBE963B368 for ; Tue, 9 Aug 2005 14:08:58 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa18040; 9 Aug 2005 10:08 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX18nx0RSBoqSaCiqN1ans4UF9lBOJ2wMtzk@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j79E8HjU001117 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Aug 2005 10:08:22 -0400 (EDT) Date: Tue, 09 Aug 2005 16:08:17 +0200 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? Message-ID: <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> In-Reply-To: <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01aPXem9JdUw+0QFYcm3MOCv9nFcbvKVfVagwAnnU=; 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 Content-Transfer-Encoding: 7bit On Tuesday, August 09, 2005 09:03:30 -0400 der Mouse wrote: >> The existing agent draft contains a lot of stuff about tagging >> forwarded agent connections at each hop, so you can tell where things >> came from. That might be interesting, but I don't see it being >> deployed any time soon. > > I believe my implementation does it correctly according to some version > of the draft (probably -01). Does that count as "deployed"? It does if anyone's running your code, I guess. But having implemented it, you know there are problems, like what to do for the links that are not over IP. >>> I also can't see any reason an implementation couldn't support both, >>> perhaps with a slight tweak to the more recent draft if, as it >>> implies, the old protocol uses the same channel type string as >>> agent-02. >> In most cases the ssh client doesn't implement the agent protocol; it >> just forwards it off to some program running on the same machine. > > That may or may not describe my implementation, depending on exactly > what you mean by "the ssh client" and "some program". In my case, the > client and the agent are implemented in the same executable, but run in > different processes. In both cases I actually mean running processes. So yes, I think that describes your implementation. >> From a practical standpoint, I think the best option is to make the >> protocol backwards-compatible and use the same channel string. >> Otherwise implementations like OpenSSH end up having to export _two_ >> ports for talking to the agent, depending on which version of the >> protocol you want it to speak. > > Ports? All the implementations I've used (including my own) use > AF_LOCAL sockets in /tmp, rather than anything with "ports". Sorry; my error. > That aside, yes, it would mean either two rendezvous points (of > whatever kind) or protocols different enough that the implementation > can tell which version is in use from the first packet - and in the > latter case you might as well use the same strings, as you say. > >> I would note that because all the messages are different, it should >> be possible to support both protocols on the same channel, and the >> current draft describes how a client can tell whether the agent >> supports the new protocol. > > Yes...but the method is an ugly kludge, because, as I read it, the > messages *aren't* all different; there's a collision between agent-02's > REQUEST_VERSION and 1.x please-list-identities. If we're going to do a > new agent protocol, I'd like to see that fixed so there's no message > number overlap. I believe that particular collision is deliberate, to allow a client to tell which version of the protocol is supported. It's possible the mechanism needs some work, in which case we should do that. Ultimately, what we're doing is providing connectivity between an ssh client and an agent, both of which implement unknown versions of the protocol. It seems to me that if we can arrange to run either version of the protocol over the same channel, we've made things a lot simpler and more likely to interoperate. > How can I best help this happen? Should I sit down with the 1.x code > and try to glark a spec for its agent forwarding protocol? It seems > inefficient for me to do that, as compared to someone who already knows > the protocol, but if it'd help I can take a swing at it. As I understand it, there isn't really an agent forwarding protocol, aside from the messages defined in the ssh spec for that purpose. They basically just channel the same protocol that is spoken between ssh client and agent, with no changes. It seems fairly straightforward to discover the basic form of the protocol from the code; it's essentially the same structure as what's defined in the agent draft, but the message numbers and contents are different. I think it's premature to write up a spec based on the old protocol, unless/until we decide we want to document and extend that and abandon what's in the agent draft. Before we can do that, I think we need to answer a few questions... - Is the tracing of forwarded connections worth keeping? - Are the messages used by the old protocol too limited, such that new messages need to be defined in order to do everything we need? - Is there some way we can add extensions to the old protocol in a sane fashion, so we don't crash the agent or desync the protocol if one side doesn't understand an extension? Some of that is a matter of opinion; some requires reading the old protocol. I don't have time this week to analyze the ssh agent protocol, but I can probably spend some time on it in the near future. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 10:52:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VT7-0000Q6-7I for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 10:52:42 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12960 for ; Tue, 9 Aug 2005 10:52:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E8F0063B368; Tue, 9 Aug 2005 14:52:36 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id 20C4963B102 for ; Tue, 9 Aug 2005 14:52:36 +0000 (UTC) Received: from wall.tick-it.de (p5082948E.dip0.t-ipconnect.de [80.130.148.142]) by mail.vapor.com (Postfix) with ESMTP id BD0BF390148; Tue, 9 Aug 2005 16:19:54 +0200 (CEST) Received: from [192.168.1.110] (helo=[192.168.1.110] ident=sircus) by wall.tick-it.de with esmtp (Exim 4.50) id 1E2UxV-00082u-Fv; Tue, 09 Aug 2005 16:20:01 +0200 Message-ID: <42F8BBD9.5030804@siliconcircus.com> Date: Tue, 09 Aug 2005 16:21:13 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> In-Reply-To: <385DCA310A222F9758B389B1@bistromath.pc.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 Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > On Tuesday, August 09, 2005 09:03:30 -0400 der Mouse > wrote: > >>> The existing agent draft contains a lot of stuff about tagging >>> forwarded agent connections at each hop, so you can tell where things >>> came from. That might be interesting, but I don't see it being >>> deployed any time soon. >> >> >> I believe my implementation does it correctly according to some version >> of the draft (probably -01). Does that count as "deployed"? > > It does if anyone's running your code, I guess. But having implemented > it, you know there are problems, like what to do for the links that are > not over IP. FWIW, we implement (client-side) both protocols. The agent in both cases is in-process. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 11:31:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2W4R-00015D-1U for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 11:31:15 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15861 for ; Tue, 9 Aug 2005 11:31:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5DAEA63B503; Tue, 9 Aug 2005 15:31:10 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id BBF1363B551 for ; Tue, 9 Aug 2005 15:31:08 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA18479; Tue, 9 Aug 2005 11:31:07 -0400 (EDT) From: der Mouse Message-Id: <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 9 Aug 2005 10:59:41 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> I believe my implementation does it correctly according to some >> version of the draft (probably -01). > But having implemented it, you know there are problems, like what to > do for the links that are not over IP. Right - though that's not a problem in practice for me, because I don't yet support anything else. > I believe that particular collision is deliberate, to allow a client > to tell which version of the protocol is supported. It's possible > the mechanism needs some work, in which case we should do that. Hmm. I'd feel more comfortable about it if the previous protocol were documented. But that's part of what we're talking about, so I think this point is actually spurious. >> How can I best help this happen? Should I sit down with the 1.x >> code and try to glark a spec for its agent forwarding protocol? > As I understand it, there isn't really an agent forwarding protocol, > aside from the messages defined in the ssh spec for that purpose. > They basically just channel the same protocol that is spoken between > ssh client and agent, with no changes. Ah, very much like agent-02 but without FORWARDING_NOTICE? Then what we need is to document that fact, and write up something for the client<->agent protocol (which I believe we should do if we try to retain the backward-compatability feature). > I think it's premature to write up a spec based on the old protocol, > unless/until we decide we want to document and extend that and > abandon what's in the agent draft. Agreed - except that, as I remarked above, if we try to retain compatability, I think a document describing the old protocol should exist somewhere. > Before we can do that, I think we need to answer a few questions... > - Is the tracing of forwarded connections worth keeping? I'm not sure. My agent implementation doesn't do anything with FORWARDING_NOTICE packets but skip them - but on the other hand, I certainly can see a potential desire that the agent not respond to "distant" requests. In my own ssh_config (I'm still using ssh 1.x on some machines) I have a lot of stanzas controlling whom I turn on agent forwarding to. It would be really convenient to be able to control this in agent configuration, controlling whom the agent is willing to act for, rather than in the ssh client configuration. The agent does need to trust the client to insert the notices, but the local ssh client is presumably trusted. > - Are the messages used by the old protocol too limited, such that > new messages need to be defined in order to do everything we need? As you note, this is approximately impossible to answer without knowing the old protocl - which for me, at least, means having some kind of description of it. But I will note that in my implementation I found I had to use private requests and channel types in order to make agent forwarding work right with connection sharing, and that's without any attempt at backward compatability. > - Is there some way we can add extensions to the old protocol in a > sane fashion, so we don't crash the agent or desync the protocol if > one side doesn't understand an extension? Again, I couldn't say without seeing a spec for the old protocol - and, if it contains the lacunae I expect it to, some kind of description for existing implementations as well. But if the existing protocol and implementations are not designed with any extension mechanism in mind, I don't think there is anything we can do here. If agents are not designed to support extensions, anything not conforming to their protocol will break them, so clients can't send anything not conforming; and if clients are not designed to support extensions, the agent cannot return anything beyond the old behaviour when responding to old requests, or it risks breaking old clients. This locks both sides into sticking to the old protocol. The only reason the existing agent drafts can do old-version sensing at all is that they aren't using the old protocol - there is a message, conforming to the old protocol, to which they assign a different meaning from what the old protocol does. We could do the same thing, but then we're not just adding extensions to the old protocol; then we're designing a new protocol with some compatability. (The major difference is that a new agent will break an old client, because it will respond in the new-protocol way to an old-protocol request. The reason the draft protocol doesn't have this problem is that they are depending on a hole in the spec interacting with a lucky property of existing implementations: the old list-identities request can, de-facto if not de-jure, exist in multiple forms, all of which the old agents accept but only one of which the old clients generate.) I see no major difference between adopting the old protocol with some extension hooks (such as taking advantage of the loophole agent-02 does) and designing a new protocol with backward compatability. It's really a question of how much of the old protocol we can steal intact and how much we need to invent - a difference of degree rather than kind. It's also something I can't really speak to without a description of the old protocol at hand, too. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 11:43:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WFv-0005Mb-A1 for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 11:43:07 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16438 for ; Tue, 9 Aug 2005 11:43:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 753AE63B376; Tue, 9 Aug 2005 15:43:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id D674E63B101 for ; Tue, 9 Aug 2005 15:43:01 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E2WFp-0003El-5k; Tue, 09 Aug 2005 11:43:01 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'GSSAPI Authentication and Key Exchange for the Secure Shell Protocol' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Tue, 09 Aug 2005 11:43:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has received a request from the Secure Shell WG to consider the following document: - 'GSSAPI Authentication and Key Exchange for the Secure Shell Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-09.txt From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 15:50:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a71-0000gn-Iy for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 15:50:11 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03676 for ; Tue, 9 Aug 2005 15:50:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9615F63B32B; Tue, 9 Aug 2005 19:50:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 9177963B2EE for ; Tue, 9 Aug 2005 19:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2a6r-0007He-SG; Tue, 09 Aug 2005 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-break-04.txt Message-Id: Date: Tue, 09 Aug 2005 15:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Secure Shell (SSH) Session Channel Break Extension Author(s) : J. Galbraith, P. Remaker Filename : draft-ietf-secsh-break-04.txt Pages : 11 Date : 2005-8-9 The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-04.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-break-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-break-04.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: <2005-8-9113806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-break-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-break-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-9113806.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 16:25:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aeo-0000XY-Li for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:25:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12373 for ; Tue, 9 Aug 2005 16:25:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 28ED663B39A; Tue, 9 Aug 2005 20:25:03 +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 5047B63B152 for ; Tue, 9 Aug 2005 20:25:02 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j79KOvi8002987; Tue, 9 Aug 2005 13:24:58 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j79KOv5K005042; Tue, 9 Aug 2005 16:24:57 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j79KOuxP006907; Tue, 9 Aug 2005 16:24:57 -0400 (EDT) Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: rodney@tillerman.to, ietf-ssh@NetBSD.org In-Reply-To: <1111442941.5683.257.camel@thunk> References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1123619096.2981.28.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Tue, 09 Aug 2005 16:24:56 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joe, It looks like we ratholed on the line termination question. I'm going to take that as an indication that nothing more serious needs to be done to the document. I believe the consensus position is to weaken section 3.1, which currently reads: > 3.1 Line Termination Characters > > Implementations are REQUIRED to read files using any of the common > line termination sequence, , or . > > Implementations may generate files using whichever of these line > termination conventions is most convenient. to instead say something along the lines of: Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . I believe this captures the core of the objections to the original section 3.1 text. Comments? - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 16:42:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2avU-0000C5-01 for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:42:20 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13333 for ; Tue, 9 Aug 2005 16:42:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 762F763B1A8; Tue, 9 Aug 2005 20:42:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id C716A63B152 for ; Tue, 9 Aug 2005 20:42:15 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7743404; Tue, 09 Aug 2005 14:42:15 -0600 Message-ID: <42F916DA.50204@vandyke.com> Date: Tue, 09 Aug 2005 14:49:30 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Bill Sommerfeld CC: rodney@tillerman.to, ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1123619096.2981.28.camel@thunk> In-Reply-To: <1123619096.2981.28.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > Joe, > > It looks like we ratholed on the line termination question. I'm going > to take that as an indication that nothing more serious needs to be done > to the document. > > I believe the consensus position is to weaken section 3.1, which > currently reads: > >> 3.1 Line Termination Characters >> >> Implementations are REQUIRED to read files using any of the common >> line termination sequence, , or . >> >> Implementations may generate files using whichever of these line >> termination conventions is most convenient. > > to instead say something along the lines of: > > Implementations SHOULD generate public key files using their > system's local text file representation. > > In the event that public key files are not transferred as text files, > implementations SHOULD be prepared to read files using any of the > common line termination sequence, , or . > > I believe this captures the core of the objections to the > original section 3.1 text. > > Comments? Expect a new draft issued in the next couple of days? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 20:45:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2eiT-00068j-W3 for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:45:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26731 for ; Tue, 9 Aug 2005 20:45:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D47C763B3B6; Wed, 10 Aug 2005 00:45:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 114D063B3B2 for ; Wed, 10 Aug 2005 00:45:00 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7750482; Tue, 09 Aug 2005 18:45:00 -0600 Message-ID: <42F94FBF.9060804@vandyke.com> Date: Tue, 09 Aug 2005 18:52:15 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: filexfer (was: Secure Shell WG: what's left?) References: <1123546167.29244.159.camel@thunk> In-Reply-To: <1123546167.29244.159.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > draft-ietf-secsh-filexfer-09 > what can I say but *sigh*. > the complexity of this draft seems to be increasing, > due largely to differences in philosophy between posix/unix and > not-posix/unix filesystems. The good news is, I think we are done increasing the complexity :-) It is in need of some serious implementing, and massive copy edit, a sledgehammer of a spell checker, but I think we are getting closer on this draft too. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 20:50:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2eno-0008JM-PJ for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:50:40 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26912 for ; Tue, 9 Aug 2005 20:50:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BF69763B170; Wed, 10 Aug 2005 00:50:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 2188363B160 for ; Wed, 10 Aug 2005 00:50:37 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7750494; Tue, 09 Aug 2005 18:50:36 -0600 Message-ID: <42F95110.7050704@vandyke.com> Date: Tue, 09 Aug 2005 18:57:52 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: x509-02 (was Secure Shell WG: what's left?) References: <1123546167.29244.159.camel@thunk> In-Reply-To: <1123546167.29244.159.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > draft-ietf-secsh-x509-02: standards track > very new. needs PKI expert review. This is very accurate reflection of this draft's status. Out of curiosity, is anybody implementing / planning to implement this draft in the near future? Anybody have any suggestions on how to catch a PKI expert? I'll send a plate of homemade chocolate chip cookies :-) A bag of MMs? Doritos? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 20:57:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2euB-0001bF-Ih for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:57:15 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27104 for ; Tue, 9 Aug 2005 20:57:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D174D63B1D2; Wed, 10 Aug 2005 00:57:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 3DC8C63B160 for ; Wed, 10 Aug 2005 00:57:12 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7750510; Tue, 09 Aug 2005 18:57:11 -0600 Message-ID: <42F9529B.9000406@vandyke.com> Date: Tue, 09 Aug 2005 19:04:27 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: publickey subsystem (was: Secure Shell WG: what's left?) References: <1123546167.29244.159.camel@thunk> In-Reply-To: <1123546167.29244.159.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > We are decidedly well into the "home stretch". > > Here's what's left on our plate: > > draft-ietf-secsh-publickey-subsystem-02: standards track. > Ready for WG Last Call? I think so... I've kinda of lost track of this one. Jon, what do you think, are we ready? I think we have several implementations of version 1 of this protocol-- I'm not sure how many we have of the current version. Does anyone know of any open issues for this draft? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 21:22:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2fIH-0002zQ-Fp for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 21:22:09 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28044 for ; Tue, 9 Aug 2005 21:22:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CB73E63B3BA; Wed, 10 Aug 2005 01:22:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 0772E63B3AE for ; Wed, 10 Aug 2005 01:22:03 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7750548; Tue, 09 Aug 2005 19:22:03 -0600 Message-ID: <42F9586F.2010300@vandyke.com> Date: Tue, 09 Aug 2005 19:29:19 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: filexfer (was: Secure Shell WG: what's left?) References: <3EF96AF20489A34296050FBD5C36ECB91883A8@beacon.PSC.process.com> <200508091303.JAA17527@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200508091303.JAA17527@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: >>> draft-ietf-secsh-filexfer-09 >>> what can I say but *sigh*. >>> the complexity of this draft seems to be increasing, >>> due largely to differences in philosophy between posix/unix and >>> not-posix/unix filesystems. >> I prefer to think of this as adding functionality needed for >> interoperability that was ignored in earlier versions of this draft. > > ...but in the process making it impossible for a moderately large class > of systems to support more than ASCII under the protocol as specified > at all. (Strictly, they can't support even that much, but can probably > get away with pretending.) Are we talking about unicode filenames? I really wish I understood your view point on this, but I don't. What is wrong with: 1. If the client does not turn off filename translation, the server should either: a. Use the true character set of the file as recorded by filesystem, if such exists. b. Pretend the user is sitting at a terminal. As such, the terminal has an encoding it uses to display text. Typicallyd , this is controlleby the LC_CTYPE or LANG environment variables, though the method of determining this encoding may differ from OS implementation to OS implementation. The server should assume that all filenames are encoded such that they would display correctly on this 'pretend' terminal, and translate from that encoding to UTF-8. c. If the OS provides no mechanism for determining the user preferred encoding, but it is still possible for user to use different encodings for filenames, the server implementation itself may have to provide a way for the user to configure their preferred encoding. d. If said translation fails, the server should set SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR, and place the untranslated name in the attrib untranslated-name field. 2. If the client does turn off filename translation, the server simply sends rthe filename data as it reads it fom disk. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 21:31:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2fRd-0007L9-IG for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 21:31:50 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28510 for ; Tue, 9 Aug 2005 21:31:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7564063B1ED; Wed, 10 Aug 2005 01:31:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from pigeon.alphaweb.net (69-12-155-130.dsl.static.sonic.net [69.12.155.130]) by mail.netbsd.org (Postfix) with ESMTP id D97AE63B1E7 for ; Wed, 10 Aug 2005 01:31:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lighthammer) by pigeon.alphaweb.net with smtp (Exim 4.10) id 1E2eq6-00060A-00 for ietf-ssh@netbsd.org; Tue, 09 Aug 2005 17:53:03 -0700 Message-ID: <000b01c59d4b$4282bee0$f32c1a44@lighthammer> Reply-To: "Sara Golemon" From: "Sara Golemon" To: Subject: Re: publickey subsystem (was: Secure Shell WG: what's left?) Date: Tue, 9 Aug 2005 18:30:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >> We are decidedly well into the "home stretch". >> >> Here's what's left on our plate: >> >> draft-ietf-secsh-publickey-subsystem-02: standards track. >> Ready for WG Last Call? > > I think so... I've kinda of lost track of this one. > > Jon, what do you think, are we ready? > > I think we have several implementations of version 1 > of this protocol-- I'm not sure how many we have of > the current version. > > Does anyone know of any open issues for this draft? > If I had a complaint about this draft it'd be the lack of a changelog describing the differences from version 1. I had to use the openssh patch provided by vandyke as a reference to learn that version 1 doesn't use generic attributes in "add" and "publickey" packets, but does use an explicit comment field. -Sara From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 22:04:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2fxX-0002W1-Ex for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 22:04:47 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29519 for ; Tue, 9 Aug 2005 22:04:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D04E763B1E1; Wed, 10 Aug 2005 02:04:42 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 2F3AD63B199 for ; Wed, 10 Aug 2005 02:04:42 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7750567; Tue, 09 Aug 2005 20:04:41 -0600 Message-ID: <42F9626D.30100@vandyke.com> Date: Tue, 09 Aug 2005 20:11:57 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Sara Golemon CC: ietf-ssh@NetBSD.org Subject: Re: publickey subsystem (was: Secure Shell WG: what's left?) References: <000b01c59d4b$4282bee0$f32c1a44@lighthammer> In-Reply-To: <000b01c59d4b$4282bee0$f32c1a44@lighthammer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sara Golemon wrote: >>> We are decidedly well into the "home stretch". >>> >>> Here's what's left on our plate: >>> >>> draft-ietf-secsh-publickey-subsystem-02: standards track. >>> Ready for WG Last Call? >> >> I think so... I've kinda of lost track of this one. >> >> Jon, what do you think, are we ready? >> >> I think we have several implementations of version 1 >> of this protocol-- I'm not sure how many we have of >> the current version. >> >> Does anyone know of any open issues for this draft? >> > If I had a complaint about this draft it'd be the lack of a changelog > describing the differences from version 1. I had to use the openssh > patch provided by vandyke as a reference to learn that version 1 doesn't > use generic attributes in "add" and "publickey" packets, but does use an > explicit comment field. Does this page help: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/ The IETF didn't use to provide this information... I think it is very useful that they do now. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 09 23:35:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hN1-0002Z4-Th for secsh-archive@megatron.ietf.org; Tue, 09 Aug 2005 23:35:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02476 for ; Tue, 9 Aug 2005 23:35:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A2A0963B3D3; Wed, 10 Aug 2005 03:35:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from pigeon.alphaweb.net (69-12-155-130.dsl.static.sonic.net [69.12.155.130]) by mail.netbsd.org (Postfix) with ESMTP id 1521863B3DB for ; Wed, 10 Aug 2005 03:35:07 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lighthammer) by pigeon.alphaweb.net with smtp (Exim 4.10) id 1E2glV-0006h5-00; Tue, 09 Aug 2005 19:56:25 -0700 Message-ID: <002b01c59d5c$7f73e160$6c051fac@lighthammer> Reply-To: "Sara Golemon" From: "Sara Golemon" To: Cc: Subject: Re: publickey subsystem (was: Secure Shell WG: what's left?) Date: Tue, 9 Aug 2005 20:35:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >> If I had a complaint about this draft it'd be the lack of a changelog >> describing the differences from version 1. I had to use the openssh >> patch provided by vandyke as a reference to learn that version 1 doesn't >> use generic attributes in "add" and "publickey" packets, but does use an >> explicit comment field. > > Does this page help: > > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/ > > The IETF didn't use to provide this information... I think it > is very useful that they do now. > Absolutely! Thanks for the resource! -Sara From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 02:04:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jhI-0006aw-NV for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 02:04:16 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13303 for ; Wed, 10 Aug 2005 02:04:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8B3F063B3EE; Wed, 10 Aug 2005 06:03:46 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 5BF4463B3E9 for ; Wed, 10 Aug 2005 06:03:45 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA03178; Wed, 10 Aug 2005 02:03:44 -0400 (EDT) From: der Mouse Message-Id: <200508100603.CAA03178@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 10 Aug 2005 02:00:57 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt In-Reply-To: <1123619096.2981.28.camel@thunk> References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1123619096.2981.28.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > It looks like we ratholed on the line termination question. [...] > I believe the consensus position is to weaken section 3.1, [to] > something along the lines of: > Implementations SHOULD generate public key files using their > system's local text file representation. > > In the event that public key files are not transferred as text > files, implementations SHOULD be prepared to read files using any > of the common line termination sequence, , or . As one of the noisier participants in the line termination blather, I'm prepared to sign off on that wording. (Maybe the second paragraph should say something more like "To ease interoperability in case public key files are...", which I think is closer to the intended meaning?) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 02:08:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jlA-0007CX-15 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 02:08:19 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17059 for ; Wed, 10 Aug 2005 02:08:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8033D63B3E9; Wed, 10 Aug 2005 06:08:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id C58DB63B3E7 for ; Wed, 10 Aug 2005 06:08:08 +0000 (UTC) Received: from wall.tick-it.de (p508290F7.dip0.t-ipconnect.de [80.130.144.247]) by mail.vapor.com (Postfix) with ESMTP id C4DBE3900E1; Wed, 10 Aug 2005 08:08:07 +0200 (CEST) Received: from [192.168.1.110] (helo=[192.168.1.110] ident=sircus) by wall.tick-it.de with esmtp (Exim 4.50) id 1E2jl8-00007U-L3; Wed, 10 Aug 2005 08:08:14 +0200 Message-ID: <42F99A3C.4090305@siliconcircus.com> Date: Wed, 10 Aug 2005 08:10:04 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith CC: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: publickey subsystem References: <1123546167.29244.159.camel@thunk> <42F9529B.9000406@vandyke.com> In-Reply-To: <42F9529B.9000406@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > Bill Sommerfeld wrote: > >> We are decidedly well into the "home stretch". >> >> Here's what's left on our plate: >> >> draft-ietf-secsh-publickey-subsystem-02: standards track. >> Ready for WG Last Call? > > > I think so... I've kinda of lost track of this one. > > Jon, what do you think, are we ready? As far as I know, we're ready - but it could be I've forgotten someone's issue. > I think we have several implementations of version 1 > of this protocol-- I'm not sure how many we have of > the current version. I've been meaning to get round to implementing it, but haven't yet. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 02:12:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jp1-0008T3-H3 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 02:12:15 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20924 for ; Wed, 10 Aug 2005 02:12:14 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8630B63B3EF; Wed, 10 Aug 2005 06:12:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id C18D463B3E7 for ; Wed, 10 Aug 2005 06:12:10 +0000 (UTC) Received: from wall.tick-it.de (p508290F7.dip0.t-ipconnect.de [80.130.144.247]) by mail.vapor.com (Postfix) with ESMTP id E5DF43900E1; Wed, 10 Aug 2005 08:12:09 +0200 (CEST) Received: from [192.168.1.110] (helo=[192.168.1.110] ident=sircus) by wall.tick-it.de with esmtp (Exim 4.50) id 1E2jp2-00007g-Oo; Wed, 10 Aug 2005 08:12:16 +0200 Message-ID: <42F99B2E.1050901@siliconcircus.com> Date: Wed, 10 Aug 2005 08:14:06 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sara Golemon CC: galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: publickey subsystem (was: Secure Shell WG: what's left?) References: <002b01c59d5c$7f73e160$6c051fac@lighthammer> In-Reply-To: <002b01c59d5c$7f73e160$6c051fac@lighthammer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sara Golemon wrote: >>> If I had a complaint about this draft it'd be the lack of a changelog >>> describing the differences from version 1. I had to use the openssh >>> patch provided by vandyke as a reference to learn that version 1 doesn't >>> use generic attributes in "add" and "publickey" packets, but does use an >>> explicit comment field. I'm not sure if such a changelog would be accepted - as I understand it, the drafts are supposed to document how things are, as opposed to how they were. I may be wrong in this. >> Does this page help: >> >> http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/ >> >> The IETF didn't use to provide this information... I think it >> is very useful that they do now. >> > Absolutely! Thanks for the resource! Does this obviate the need for a Changelog, or did you mean that it's a useful resource, but we still need a Changelog? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 02:47:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2kNF-0008Jj-G3 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 02:47:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08099 for ; Wed, 10 Aug 2005 02:47:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4C85063B4EA; Wed, 10 Aug 2005 06:47:34 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C8D3C63B11F for ; Wed, 10 Aug 2005 06:47:32 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA03313; Wed, 10 Aug 2005 02:47:32 -0400 (EDT) From: der Mouse Message-Id: <200508100647.CAA03313@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 10 Aug 2005 02:11:45 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: filexfer (was: Secure Shell WG: what's left?) In-Reply-To: <42F9586F.2010300@vandyke.com> References: <3EF96AF20489A34296050FBD5C36ECB91883A8@beacon.PSC.process.com> <200508091303.JAA17527@Sparkle.Rodents.Montreal.QC.CA> <42F9586F.2010300@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>> the complexity of this draft seems to be increasing, >>>> due largely to differences in philosophy between posix/unix and >>>> not-posix/unix filesystems. >>> I prefer to think of this as adding functionality needed for >>> interoperability that was ignored in earlier versions of this >>> draft. >> ...but in the process making it impossible for a moderately large >> class of systems to support more than ASCII under the protocol as >> specified at all. (Strictly, they can't support even that much, but >> can probably get away with pretending.) > Are we talking about unicode filenames? Well, I was, at least. > I really wish I understood your view point on this, but I don't. > What is wrong with: > 1. If the client does not turn off filename translation, > the server should either: > a. Use the true character set of the file as recorded by > filesystem, if such exists. Of course. The "moderately large class of systems" I refer to is those for which file names as recorded by the filesystem are octet sequences rather than character sequences, and thus this condition fails. > b. Pretend the user is sitting at a terminal. As such, > the terminal has an encoding it uses to display text. Yes, but the server has no way to tell what it is. The window I'm typing this mail into happens to be using a font which is basically ISO 8859-1 (it's 8859-1 plus some glyphs in positions where 8859-1 does not have printable characters). If I were to tell it to switch to, say, an 8859-7 font, a hypothetical sftp running in that window would have no way to even realize any change occurred, much less get enough details to do anything useful with it. And a server process would be even more disconnected from that encoding change. You could argue that this is a bug in the OS design, failing to treat data as characters (with character-set information attached) rather than uninterpreted blobs of bits. But even if I were to agree with you, such systems still exist, and I think that rendering filexfer-* unimplementable on them would be a critical problem (especially as an implementer who works primarily on one of them). > c. If the OS provides no mechanism for determining the user > preferred encoding, but it is still possible for user to use > different encodings for filenames, Exactly the situation that concerns me: an OS which provides no mechanism for determining from a file name what character set was intended by that name's creator - or indeed whether any was - but which happily lets users use whatever encoding their display/input hardware/software happens to use. > the server implementation itself may have to provide a way for > the user to configure their preferred encoding. Perhaps. It's not a wholly unreasonable thing to provide. It doesn't answer the question of what to do if none has been configured, though. (Requiring that one be configured strikes me as excessive, especially given the lack of any standardized character set, as far as I know, which assigns characters to all 256 possible octet values.) > d. If said translation fails, the server should set > SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR, and place > the untranslated name in the attrib untranslated-name > field. This actually does provide a mostly-reasonable tack to take: always do that. (Possibly except when the name is pure ASCII, though assuming even that much can be dangerous; consider a system some users of which like EBCDIC...or, less far-fetched, KOI-7.) After all, a lack of character set information (which is the fundamental problem here) _can_ be looked on as an error arising when attempting to translate an octet string to Unicode. I don't think ATTR_FLAGS_TRANSLATION_ERR and untranslated-name were in the previous version; I'm glad to see them. Even when there *is* character set information available, there needs to be something to do when, for example, an octet is encoutered which has no corresponding character in the set the string is marked as using. I do note that filexfer-09 provides no guidance on what to put in the UTF-8-encoded name field when a translation error occurs (a recommendation for "zero-length string" or "best effort" or some such would probably be a Good Thing). > 2. If the client does turn off filename translation, the server > simply sends rthe filename data as it reads it fom disk. Of course. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 06:23:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nkS-0006Rt-F6 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:23:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18355 for ; Wed, 10 Aug 2005 06:23:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 05F1A63B127; Wed, 10 Aug 2005 10:23:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 9FE3763B175 for ; Wed, 10 Aug 2005 10:23:42 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa00783; 10 Aug 2005 6:23 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX1+O6Ppomb6g9fSCoTJEpKd7AOVrZpOGSO0@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7AANM7U006102 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 Aug 2005 06:23:27 -0400 (EDT) Date: Wed, 10 Aug 2005 12:23:23 +0200 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? Message-ID: In-Reply-To: <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01+HOfDmLbFIJEvhePK/HPfY/l1jl/pxhl6M1zLvM=; 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 Content-Transfer-Encoding: 7bit On Tuesday, August 09, 2005 10:59:41 -0400 der Mouse wrote: >>> I believe my implementation does it correctly according to some >>> version of the draft (probably -01). >> But having implemented it, you know there are problems, like what to >> do for the links that are not over IP. > > Right - though that's not a problem in practice for me, because I don't > yet support anything else. > >> I believe that particular collision is deliberate, to allow a client >> to tell which version of the protocol is supported. It's possible >> the mechanism needs some work, in which case we should do that. > > Hmm. I'd feel more comfortable about it if the previous protocol were > documented. But that's part of what we're talking about, so I think > this point is actually spurious. The way I see it, we have two choices. We can either extend the old protocol, or define a new one (which may or may not be based on the existing agent drafts). If we choose to extend the old protocol, then of course we need to document it. If we define a new agent protocol, then we only need enough documentation about the old one to allow for version negotation and allow implementations that want to support both versions to do so -- just as we did with the core ssh protocol and sshv1. >> Before we can do that, I think we need to answer a few questions... > >> - Is the tracing of forwarded connections worth keeping? > > I'm not sure. My agent implementation doesn't do anything with > FORWARDING_NOTICE packets but skip them - but on the other hand, I > certainly can see a potential desire that the agent not respond to > "distant" requests. In my own ssh_config (I'm still using ssh 1.x on > some machines) I have a lot of stanzas controlling whom I turn on agent > forwarding to. It would be really convenient to be able to control > this in agent configuration, controlling whom the agent is willing to > act for, rather than in the ssh client configuration. > > The agent does need to trust the client to insert the notices, but the > local ssh client is presumably trusted. It does seem useful for that, if people are actually going to implement such policy. If no one is going to use it, then it's pointless to define it. > But I will note that in my implementation I found I had to use private > requests and channel types in order to make agent forwarding work right > with connection sharing, and that's without any attempt at backward > compatability. Hrm; that's interesting. If the current request and channel type are inadequate, maybe we need to define new ones. It'd still be nice, I think, to avoid tying the agent protocol version to the type of channel it runs on, if we can avoid it. > We could do the same thing, but then we're not just adding extensions > to the old protocol; then we're designing a new protocol with some > compatability. (The major difference is that a new agent will break an > old client, because it will respond in the new-protocol way to an > old-protocol request. The reason the draft protocol doesn't have this > problem is that they are depending on a hole in the spec interacting > with a lucky property of existing implementations: the old > list-identities request can, de-facto if not de-jure, exist in multiple > forms, all of which the old agents accept but only one of which the old > clients generate.) I suspect the situation is very similar to that for sshv1 - there are implementations of the existing protocol, but no formal specs. That may mean we have to survey the existing implementations and try to do something that doesn't break any of them. That's unfortunate, but sometimes you have to do that sort of thing to make progress. The important thing is that we don't repeat any mistakes we might find, like lack of a spec. FWIW, about a month ago I was reading openssh agent code as part of the process of designing an agent extension I was thinking about (for accessing Kerberos ccache's via the ssh agent). I _think_ I found that the openssh agent reacts in a sane way to unknown messages. I _think_ their extensions for smartcard support depend on this behavior. > I see no major difference between adopting the old protocol with some > extension hooks (such as taking advantage of the loophole agent-02 > does) and designing a new protocol with backward compatability. It's > really a question of how much of the old protocol we can steal intact > and how much we need to invent - a difference of degree rather than > kind. It's also something I can't really speak to without a > description of the old protocol at hand, too. I think this is a fair analysis of the situation. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 06:24:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nkg-0006ie-Nf for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:24:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18360 for ; Wed, 10 Aug 2005 06:23:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BB6FF63B18E; Wed, 10 Aug 2005 10:23:57 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mail.netbsd.org (Postfix) with ESMTP id C33DD63B175 for ; Wed, 10 Aug 2005 10:23:56 +0000 (UTC) Received: from dodgynet.dyndns.org (203-217-17-96.perm.iinet.net.au [203.217.17.96]) (authenticated bits=0) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j7AA0r6X008314 for ; Wed, 10 Aug 2005 20:00:54 +1000 Received: from dodgynet.dyndns.org (localhost [127.0.0.1]) by dodgynet.dyndns.org (8.13.1/8.13.1) with ESMTP id j7AA0rxl024669 for ; Wed, 10 Aug 2005 20:00:53 +1000 Received: (from dtucker@localhost) by dodgynet.dyndns.org (8.13.1/8.12.8/Submit) id j7AA0qZE024668 for ietf-ssh@NetBSD.org; Wed, 10 Aug 2005 20:00:52 +1000 X-Authentication-Warning: gate.dodgy.net.au: dtucker set sender to dtucker@zip.com.au using -f Date: Wed, 10 Aug 2005 20:00:52 +1000 From: Darren Tucker To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? Message-ID: <20050810100052.GA12527@gate.dodgy.net.au> Reply-To: dtucker@zip.com.au References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.2.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Aug 08, 2005 at 09:40:00PM -0400, der Mouse wrote: > > Here's what's left on our plate: > > > draft-ietf-secsh-agent-02 (Expired) > > I'm prepared to write this one off for lack of interest. > > ...?? Am I really the only implementor who bothers to do agent > forwarding?! I note that the draft contains the following unspecified IPR claim: [quote] The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. [/quote] however I can find no reference to the specifics. Plugging the draft name into https://datatracker.ietf.org/public/ipr_search.cgi returns: Search result on draft-ietf-secsh-agent, "Secure Shell Authentication Agent Protocol" No IPR disclosures related to draft-ietf-secsh-agent have been submitted -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 06:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nwR-00012d-Vp for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:36:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18919 for ; Wed, 10 Aug 2005 06:36:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DA15763B1B2; Wed, 10 Aug 2005 10:36:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 893BC63B1A5 for ; Wed, 10 Aug 2005 10:36:06 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa00827; 10 Aug 2005 6:35 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX1+xkpC/KLC2+4D33+f6BGOvfA97tmFRjoU@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7AAZmjR006158 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 Aug 2005 06:35:51 -0400 (EDT) Date: Wed, 10 Aug 2005 12:35:49 +0200 From: Jeffrey Hutzelman To: Jon Bright , Sara Golemon cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: publickey subsystem (was: Secure Shell WG: what's left?) Message-ID: <1CF6C25F3BBC29640379E498@bistromath.pc.cs.cmu.edu> In-Reply-To: <42F99B2E.1050901@siliconcircus.com> References: <002b01c59d5c$7f73e160$6c051fac@lighthammer> <42F99B2E.1050901@siliconcircus.com> Originator-Info: login-token=Mulberry:012WX4R0PNbbslsHDIDOMotnDXL3JgmXFG2iasD+U=; 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 Content-Transfer-Encoding: 7bit On Wednesday, August 10, 2005 08:14:06 +0200 Jon Bright wrote: > Sara Golemon wrote: >>>> If I had a complaint about this draft it'd be the lack of a changelog >>>> describing the differences from version 1. I had to use the openssh >>>> patch provided by vandyke as a reference to learn that version 1 >>>> doesn't use generic attributes in "add" and "publickey" packets, but >>>> does use an explicit comment field. > > I'm not sure if such a changelog would be accepted - as I understand it, > the drafts are supposed to document how things are, as opposed to how > they were. I may be wrong in this. Every internet draft contains the following notices: 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 general IETF philosophy is that while running code is nice, using an internet-draft as the basis for implementation is often inappropriate. While we've done so in several cases in this WG, the IETF usually does not do things like rev protocol versions with each version of an I-D, or take other measures to make sure implementations built against old I-D's will interoperate with the final standard. In other words, looking at old I-D versions is useful for historical perspective, but in most cases no one expects implementations to support anything but the final protocol. If there is a large installed base of implementations based on an old draft that you care about interoperating with, then by all means implement that draft. But that old draft does not have any particular standing. I don't know if there is a large deployed base of publickey-subsystem-01. As an operator and end-user, I don't think it would bother me even a little if implementations of this protocol did not support older drafts. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 06:38:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nz1-0001nW-NS for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:38:51 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19093 for ; Wed, 10 Aug 2005 06:38:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D1B163B1C6; Wed, 10 Aug 2005 10:38:48 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id F117B63B165 for ; Wed, 10 Aug 2005 10:38:46 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa00846; 10 Aug 2005 6:38 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX18DWY9WZw27gxxxEYbs5ODRM1LXmMQDplg@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7AAcYEL006161 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 Aug 2005 06:38:36 -0400 (EDT) Date: Wed, 10 Aug 2005 12:38:35 +0200 From: Jeffrey Hutzelman To: Joseph Galbraith , Bill Sommerfeld cc: ietf-ssh@NetBSD.org Subject: Re: x509-02 (was Secure Shell WG: what's left?) Message-ID: <69C9813E2094C1E8ED549A12@bistromath.pc.cs.cmu.edu> In-Reply-To: <42F95110.7050704@vandyke.com> References: <1123546167.29244.159.camel@thunk> <42F95110.7050704@vandyke.com> Originator-Info: login-token=Mulberry:01uDXmiSKdW/0EgF4K67MW+E+nHbQ/aV8lqhTu7rU=; 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 Content-Transfer-Encoding: 7bit On Tuesday, August 09, 2005 18:57:52 -0600 Joseph Galbraith wrote: > Anybody have any suggestions on how to catch > a PKI expert? I bet Bill could ask our friendly neighborhood AD to provide one. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 06:48:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2o8o-0005MZ-R9 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:48:59 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19393 for ; Wed, 10 Aug 2005 06:48:55 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9FE8563B175; Wed, 10 Aug 2005 10:48:54 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id C2DAC63B165 for ; Wed, 10 Aug 2005 10:48:53 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa00901; 10 Aug 2005 6:48 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX1+/3BuRRWHEwtdnTjpo4o90DdYvVlMR3zQ@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7AAmffg006228 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 Aug 2005 06:48:46 -0400 (EDT) Date: Wed, 10 Aug 2005 12:48:42 +0200 From: Jeffrey Hutzelman To: dtucker@zip.com.au, ietf-ssh@NetBSD.org Subject: Agent IPR issues (was Re: Secure Shell WG: what's left?) Message-ID: In-Reply-To: <20050810100052.GA12527@gate.dodgy.net.au> References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <20050810100052.GA12527@gate.dodgy.net.au> Originator-Info: login-token=Mulberry:01/Pzug2ZkY/dIR2YEL3oe8pNuJa6DMGdpcRzoMnw=; 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 Content-Transfer-Encoding: 7bit On Wednesday, August 10, 2005 20:00:52 +1000 Darren Tucker wrote: > I note that the draft contains the following unspecified IPR claim: > > [quote] > The IETF has been notified of intellectual property rights claimed in > regard to some or all of the specification contained in this document. > For more information consult the online list of claimed rights. > [/quote] At the time that draft was written, the text you quoted was the standard boilerplate to be used when an IPR claim had been received that was alleged or believed to apply to that document. Since then, I believe the boilerplate has been changed such that it doesn't say whether there is a specific claim related to this document, consistent with the IETF's policy of not taking positions wrt IPR claims. > however I can find no reference to the specifics. Plugging the draft > name into https://datatracker.ietf.org/public/ipr_search.cgi returns: > > Search result on draft-ietf-secsh-agent, "Secure Shell Authentication > Agent Protocol" > No IPR disclosures related to draft-ietf-secsh-agent have been > submitted I did rather more searches than that, and I couldn't come up with anything, either. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 08:53:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2q5j-0005AK-8Y for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 08:53:55 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25103 for ; Wed, 10 Aug 2005 08:53:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4B9BC63B16A; Wed, 10 Aug 2005 12:53:51 +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 6FAEE63B108 for ; Wed, 10 Aug 2005 12:53:50 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: publickey subsystem Date: Wed, 10 Aug 2005 08:56:09 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB91883AB@beacon.PSC.process.com> Thread-Topic: publickey subsystem Thread-Index: AcWdcjs3RKziHJ5/QXGgBmzhbjRg3AAOAjZQ From: "Richard Whalen" To: "Jon Bright" , "Joseph Galbraith" Cc: "Bill Sommerfeld" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I've implemented both versions. I've used the version 1 implementation = with the VanDyke software pieces, but I have not done any = interoperability testing with the current version. I have no issues with the current draft, and I think that it is ready = for WG Last Call. ---------------------- Richard Whalen Process Software From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 12:38:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2tb5-0006Qu-NG for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 12:38:32 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09880 for ; Wed, 10 Aug 2005 12:38:28 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1F13D63B5BC; Wed, 10 Aug 2005 16:38:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 86FE963B5BF for ; Wed, 10 Aug 2005 16:38:24 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA06045; Wed, 10 Aug 2005 12:38:15 -0400 (EDT) From: der Mouse Message-Id: <200508101638.MAA06045@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 10 Aug 2005 12:09:26 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> I will note that in my implementation I found I had to use private >> requests and channel types in order to make agent forwarding work >> right with connection sharing, and that's without any attempt at >> backward compatability. > Hrm; that's interesting. If the current request and channel type are > inadequate, maybe we need to define new ones. My request and channel type are the same as the ones agent-02 4.1 and 4.2, except that each one has a uint32 appended to it (and they have private names, of course). This uint32 is an opaque cookie (opaque to the server side, that is) that allows the client to tell which request, and therefore which session channel, a given agent channel open attempt corresponds to: an agent connection open packet includes the cookie from the matching agent forwarding request packet. Otherwise, if you have two sessions on a shared channel, both of which have requested auth agent forwarding, the connection-sharing multiplexer on the client side can't tell which session, and therefore which of the multiplexer's clients, a given agent connection goes with. (It matters if the two clients are talking with different agents.) This does lose one capability of the stock protocol, that being agent connection opens without corresponding agent forwarding requests. I don't consider this a significant loss, especially since I agree with agent-02 that "Implementations MUST reject [auth-agent channel open] messages unless they have previously requested agent forwarding". I had to do similar things for X forwarding too, though in that case I consider x11-req (as in connect-25 6.3.1) and x11 (connect-25 6.3.2) broken enough that I don't even try to be compatible with them. (For agent forwarding, my code falls back to using the agent-02 mechanisms if the other end doesn't use my fixed versions, and simply doesn't work through connection sharing then.) I've been told modern openssh does connection sharing - when I was at BSDCan in May another person there showed me a manpage including an option for it. Does anyone here know what they do about this issue, how they deal with the "which session does this agent channel open go with" question? If there's some way to do it with the stock request and channel type, I'd very much like to know it - but I sure can't see one; I think there simply isn't enough information. > It'd still be nice, I think, to avoid tying the agent protocol > version to the type of channel it runs on, if we can avoid it. By "channel" do you mean the thing connect-25 speaks of as a channel, or do you mean it in a more generic sense? Either way, I don't see any such dependency in either agent-02 or my mutated version of it. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 13:27:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uMv-0003ex-MS for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:27:59 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12483 for ; Wed, 10 Aug 2005 13:27:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 16ACE63B13D; Wed, 10 Aug 2005 17:27:54 +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 7324163B104 for ; Wed, 10 Aug 2005 17:27:53 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7AHRp1d000196; Wed, 10 Aug 2005 10:27:51 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7AHRolM022388; Wed, 10 Aug 2005 13:27:50 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7AHRncR010228; Wed, 10 Aug 2005 13:27:49 -0400 (EDT) Subject: WG Last Call on draft-ietf-secsh-publickey-subsystem-02 From: Bill Sommerfeld To: Richard Whalen Cc: Jon Bright , Joseph Galbraith , ietf-ssh@NetBSD.org In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB91883AB@beacon.PSC.process.com> References: <3EF96AF20489A34296050FBD5C36ECB91883AB@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1123694868.10124.24.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 10 Aug 2005 13:27:49 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit This message marks the start of a Working Group Last Call on draft-ietf-secsh-publickey-subsystem-02, for publication as a Proposed Standard. This last call period expires on August 24th, 2005. During this Last Call period, comments supporting publication are encouraged as are comments pointing out problems or suggesting changes to the spec. Reports of successful implementation of this draft are encouraged. As a reminder, tests of interoperability are *not* a prerequisite for publication as Proposed Standard but any obstacles to implementation or spec ambiguities should be corrected before publication. Please send comments to the WG list as a whole. Reports of minor problems (typos) will not delay advancement of this document. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 13:28:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uNv-00045T-Ro for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:28:59 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12570 for ; Wed, 10 Aug 2005 13:28:56 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C0B6163B14C; Wed, 10 Aug 2005 17:28:56 +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 30E2263B104 for ; Wed, 10 Aug 2005 17:28:56 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7AHSt1d001817 for ; Wed, 10 Aug 2005 10:28:55 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7AHStlM022703; Wed, 10 Aug 2005 13:28:55 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7AHStxR010233; Wed, 10 Aug 2005 13:28:55 -0400 (EDT) Subject: WG Chair Nits on draft-ietf-secsh-publickey-subsystem-02 From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1123694934.10124.27.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 10 Aug 2005 13:28:55 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I've reviewed the draft and found a few nits. 1) General: "SECSH" is the WG acronym, chosen because there was a Site Security Handbook WG at the time our WG was started. It does not name the protocol. Other WG documents have named the protocol as "Secure Shell" or "SSH". 2) The Abstract should not contain references (allowing abstracts to stand alone when excerpted). 3) in section 2.3.1, you reference RFC2279 (obsoleted by RFC3269) and RFC1766 (obsoleted by 3066 and 3282). There's no need to re-spin the document right now; wait until the end of the Last Call period so you can catch any other issues at the same time. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 13:31:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uQF-0004vl-Mf for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:31:23 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12702 for ; Wed, 10 Aug 2005 13:31:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4379663B2B8; Wed, 10 Aug 2005 17:31:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 61EF063B3DE for ; Wed, 10 Aug 2005 17:31:14 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa06699; 10 Aug 2005 13:29 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX19qAGmUvwR40GxovSViA+TWJc2uBHuad+o@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7AHTSam007774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 Aug 2005 13:29:32 -0400 (EDT) Date: Wed, 10 Aug 2005 19:29:29 +0200 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? Message-ID: <974D044178510949B0A2963F@bistromath.pc.cs.cmu.edu> In-Reply-To: <200508101638.MAA06045@Sparkle.Rodents.Montreal.QC.CA> References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> <200508101638.MAA06045@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01wclvyisx5D4NFOdL9EefOVg7pvVI/eguPp0v90k=; 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 Content-Transfer-Encoding: 7bit On Wednesday, August 10, 2005 12:09:26 -0400 der Mouse wrote: > I've been told modern openssh does connection sharing - when I was at It claims to have such switches. I've not tried using it. Maybe I will, just to see what happens. I certainly haven't read the code with respect to this behavior, but maybe I will. >> It'd still be nice, I think, to avoid tying the agent protocol >> version to the type of channel it runs on, if we can avoid it. > > By "channel" do you mean the thing connect-25 speaks of as a channel, > or do you mean it in a more generic sense? I meant in the ssh sense. > Either way, I don't see any such dependency in either agent-02 or my > mutated version of it. Good. Off to dinner now. I'll look at this more later... -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 15:12:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vzu-00012B-N8 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 15:12:18 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20632 for ; Wed, 10 Aug 2005 15:12:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9DD0D63B26F; Wed, 10 Aug 2005 19:12:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 0E83263B129 for ; Wed, 10 Aug 2005 19:12:14 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E2vzp-0001cm-NO; Wed, 10 Aug 2005 15:12:13 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Secure Shell (SSH) Session Channel Break Extension' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Wed, 10 Aug 2005 15:12:13 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has received a request from the Secure Shell WG to consider the following document: - 'Secure Shell (SSH) Session Channel Break Extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-04.txt From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 10 18:08:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2yk2-0002ZM-H7 for secsh-archive@megatron.ietf.org; Wed, 10 Aug 2005 18:08:06 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06744 for ; Wed, 10 Aug 2005 18:08:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4B26563B1CD; Wed, 10 Aug 2005 22:08:01 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 79E6563B2A8 for ; Wed, 10 Aug 2005 22:07:59 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA07620; Wed, 10 Aug 2005 18:07:58 -0400 (EDT) Date: Wed, 10 Aug 2005 18:07:58 -0400 (EDT) From: der Mouse Message-Id: <200508102207.SAA07620@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call on draft-ietf-secsh-publickey-subsystem-02 In-Reply-To: <1123694868.10124.24.camel@thunk> References: <3EF96AF20489A34296050FBD5C36ECB91883AB@beacon.PSC.process.com> <1123694868.10124.24.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > This message marks the start of a Working Group Last Call on > draft-ietf-secsh-publickey-subsystem-02, for publication as a > Proposed Standard. > Please send comments to the WG list as a whole. Here are mine. I'll leave it up to the WG and/or the document author/editor which of these are worth doing; I'm just listing everything I notice - put it this way: if I had sole responsibility for the document, these are changes I'd make. For changes where I think something should be changed but I give no specific wording, I'll be happy to have a stab at writing up wording if anyone wants. In 2.1: The public-key subsystem is opened when the clients sends a SSH_MSG_CHANNEL_REQUEST over an existing session. This has so many minor mistakes that rather than try to fix each one individually, I'll just propose a rewrite: The public-key subsystem is opened by a client sending a SSH_MSG_CHANNEL_REQUEST over an existing session's channel. Fourteen lines further down in 2.1: Client implementations SHOULD reject this request; it is normally only sent by the client. s/only sent/sent only/ Nine lines further down: authenticated with a restricted public key that does not allow access to the publickey subsystem. Proposed rewrite: authenticated by a means (such as a restricted public key) that does not allow access to the publickey subsystem. In 2.2: The length field describes the length of the request-name field and the request-specific data, but not of the length field itself. The s/but not of/but does not include/ A few lines further down, I see "the...'data' portion of the packet", but there is no field called "data": uint32 length string request-name ... request specific data follows My preferred fix here is to s/'data'/the data/. I'd like to see something explicit in 2.3 stating that the length works the same way it does in 2.2 - perhaps 2.2 and the non-subsectioned portion of 2.3 could be collapsed, since they otherwise will include a lot of duplicated, or nearly duplicated, language? In 2.3.1.1, I see no description of what the intended semantics of the return codes are, except for the description implicit in their names. Do we have consensus that this is sufficient? While I think it probably is for native anglophones, I don't have any other perspective on it myself - and even if it is sufficient, I'd prefer to see a short statement to that effect. Section 3 ("Public-Key Subsystem Operations") starts by saing that "[t]he public-key subsystem currently defines four operations: add, remove, list, and listattributes", and then proceeds to section 3.1, which describes something (version negotiation) that does not appear to be any of those four and therefore I would argue does not belong in section 3 as it currently stands. In 3.1, in case of an unsupported version, "[b]efore closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent". But 2.3.1, which describes status messages, writes of them only as responses to requests, and the version packet is not described as a request (though it fits the format of requests). I'm not sure this is worth fixing, though I'd prefer to see a brief note recognizing this slight mismatch, such as .... Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent, even though the "version" packet is not a normal request. In 3.2, I see algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add. but, in contrast to the error conditions described in the previous paragraph, I see no indication of what error code should be used. (I also don't see any error code whose name makes it look suited to this error condition, and GENERAL_FAILURE is notably unhelpful.) In 3.2, describing the "comment-language" attribute, [5]. The client MAY specify more than comment if it additionally specifies a different language for each of those comments. The Based on the context, I believe s/more than /&one / is needed here. In 3.2, describing the "subsystem" attribute, on first sight, it appears that there is no way to specify a key that permits any subsystem. (Presumably the way is to not specify the attribute at all. But this is not obvious at first sight; indeed, it wasn't until I was writing the first version of this paragraph that I realized it.) In 3.3, no indication is given of what to do if the removal succeeds, or for that matter if it fails. (I assume SUCCESS and KEY_NOT_FOUND are the principal return codes, with a few others like ACCESS_DENIED possible, but I'd still rather see it explicit.) In 3.4, no explicit provision is made for servers that support the request but choose to deny it for the client in question. I'd prefer to see this changed. In 3.2 and 3.5, no provision is made for a server that supports a specific attribute but is administratively set to impose a lack of that attribute - only for imposing the presence of an attribute. There also is no provision for cases such as imposing certain hosts' presence or absence in (say) the "agent" list. In 5.2.1, there is a restriction in that the length limit applies even to domain-localized names. This seems semi-broken, since FQDNs can be relatively long (though 64 seems generous now, I have little confidence it will remain so - I already have a private name 43 characters long). Unless the "names" in "[n]ames are case-sensitive, and MUST NOT be longer than 64 characters" refers to just the part before the @, in which case I think the language needs clarification - this section uses "name" to refer to both the whole string and just the part before the @, which is confusing; consider "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.", which uses the word in both senses in the same sentence. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 11 06:26:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3AGg-0001qM-DF for secsh-archive@megatron.ietf.org; Thu, 11 Aug 2005 06:26:35 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21742 for ; Thu, 11 Aug 2005 06:26:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 38EC763B193; Thu, 11 Aug 2005 10:26:28 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id E3B3E63B180 for ; Thu, 11 Aug 2005 10:26:26 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa23214; 11 Aug 2005 6:26 EDT Received: from p131.kthopen.kth.se (IDENT:U2FsdGVkX1+o+9fWw72cTkTx+8f0LLNXxuGpJP+A3Xw@p131.kthopen.kth.se [130.237.5.131]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7BAQ2wX011817 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 Aug 2005 06:26:04 -0400 (EDT) Date: Thu, 11 Aug 2005 12:26:03 +0200 From: Jeffrey Hutzelman To: Sam Hartman , sommerfeld@sun.com, David.Leonard@quest.com cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments Message-ID: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01vYDFWCfoOswJyz3Z8P71x1Ty/INEtD4q9fO98wA=; 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 Content-Transfer-Encoding: 7bit David Leonard wrote: > Here are my comments about draft-ietf-secsh-gsskeyex-09.txt having > worked with it to implement it in PuTTY a few weeks back. > > * s4 In the par. starting with "The server SHOULD ...": the word "not" > is missing in the first sentence, i.e. "this method has *not* > already been tried". At least that's what would make sense. I think you mean the paragraph starting with "The client SHOULD". And yes, I agree, the word "not" is missing; I've fixed it in my source. > * s7.1 In the last phrase "the hostname of the SSH server": Sometimes > users specify IP addresses instead of hostnames, and the GSS mechanism > is expected to deal with it (rightly so). Now, my concern is with the > use of the word 'hostname' in the case of targets specified as network > addresses. As written the par seems to imply a client ought to do > reverse DNS if an IP address is given. So I suggest changing "the > hostname of the SSH server" to "the given name of the SSH server" or > something like that. I believe the existing text is correct. The construction of GSSAPI host-based service names requires a hostname, not an IP address. Yes, that means that if the user provides an IP address, the server will need to reverse-resolve in a secure fashion. I think this is something the WG should comment on. > * s3.7 "This packet should be sent ...": The word "should" be > capitalized to clarify its meaning? Possibly. This text dates back to the original GSSAPI userauth draft, so perhaps Joseph Galbraith can shed some light on whether he intended this to have the force of requirements language. > * some minor typos: "environements", "gorups" Fixed in source. > One larger issue with GSS and KEX is that when a client decides to use > offer GSSKEX it queries GSS for available mechanisms and then offers these > during KEXINIT in the kex algs list. Later, during gss_init_sec_ctx, > the mechanism might fail (expired credentials, say). But by then > it is too late, as errors in KEXINIT are irrecoverable, it makes getting > a session impossible. The real problem is that an implementation has to > predict which GSS mechanisms will always fail (and therefore omit them > from the the offered kex algs list to proceed). One approach is to > iteratively retry the connection, disable gss mechanisms as they fails. > This is not addressed by the current draft, and I do not know if there > is a better approach, or a better way to allocate blame :) As Sam noted, an implementation strategy that works fairly well is to make the first call to gss_init_sec_context before deciding whether to include a particular GSSAPI-based keyex algorithm in the KEXINIT list. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 11 08:11:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Bto-0001Oz-KA for secsh-archive@megatron.ietf.org; Thu, 11 Aug 2005 08:11:05 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26455 for ; Thu, 11 Aug 2005 08:11:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B3A5363B1AD; Thu, 11 Aug 2005 12:10:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fsau.vintela.com (unknown [202.183.100.57]) by mail.netbsd.org (Postfix) with ESMTP id DA81863B1AB for ; Thu, 11 Aug 2005 12:10:56 +0000 (UTC) Received: from lark.vintela.com (lark.vintela.com [10.20.36.133]) by fsau.vintela.com (Postfix) with ESMTP id EA4DD32E3D; Thu, 11 Aug 2005 22:10:57 +1000 (EST) Date: Thu, 11 Aug 2005 22:10:54 +1000 (EST) From: David Leonard X-X-Sender: davidl@lark.vintela.com To: Jeffrey Hutzelman Cc: Sam Hartman , sommerfeld@sun.com, ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments In-Reply-To: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> Message-ID: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> Organization: Vintela; Quest Software MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 11 Aug 2005, Jeffrey Hutzelman wrote: > > * s4 In the par. starting with "The server SHOULD ...": the word "not" > > is missing in the first sentence, i.e. "this method has *not* > > already been tried". At least that's what would make sense. > > I think you mean the paragraph starting with "The client SHOULD". And yes, I > agree, the word "not" is missing; I've fixed it in my source. Yes, I meant to say the "The client SHOULD" paragraph, as you deduced. > > * s7.1 In the last phrase "the hostname of the SSH server": Sometimes > > users specify IP addresses instead of hostnames, and the GSS mechanism > > is expected to deal with it (rightly so). Now, my concern is with the > > use of the word 'hostname' in the case of targets specified as network > > addresses. As written the par seems to imply a client ought to do > > reverse DNS if an IP address is given. So I suggest changing "the > > hostname of the SSH server" to "the given name of the SSH server" or > > something like that. > > I believe the existing text is correct. The construction of GSSAPI host-based > service names requires a hostname, not an IP address. Yes, that means that if > the user provides an IP address, the server will need to reverse-resolve in a > secure fashion. No. I read RFC2743 s4.1 to say that the canonicalizing of the "hostname" string is the job of the GSS mechanism, and not that of the SSH server code. If you agree, then I think a better correction is to just quote the word "hostname" in the last sentence of s7.1, as was done in rfc2743 s4.1. > > One larger issue with GSS and KEX is that when a client decides to use > > offer GSSKEX it queries GSS for available mechanisms and then offers these > > during KEXINIT in the kex algs list. Later, during gss_init_sec_ctx, > > the mechanism might fail (expired credentials, say). But by then > > it is too late, as errors in KEXINIT are irrecoverable, it makes getting > > a session impossible. The real problem is that an implementation has to > > predict which GSS mechanisms will always fail (and therefore omit them > > from the the offered kex algs list to proceed). One approach is to > > iteratively retry the connection, disable gss mechanisms as they fails. > > This is not addressed by the current draft, and I do not know if there > > is a better approach, or a better way to allocate blame :) > > As Sam noted, an implementation strategy that works fairly well is to make the > first call to gss_init_sec_context before deciding whether to include a > particular GSSAPI-based keyex algorithm in the KEXINIT list. and less subject to degradation attacks too -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia VoIP: US: 801-655-2755 AU: 07-3023-5133 "With Quest Software, you can expect more." From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 11 11:09:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Ege-0000AA-LA for secsh-archive@megatron.ietf.org; Thu, 11 Aug 2005 11:09:43 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08114 for ; Thu, 11 Aug 2005 11:09:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 13C4C63B237; Thu, 11 Aug 2005 15:09:36 +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 EEA7463B235 for ; Thu, 11 Aug 2005 15:09:34 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9B07BE0049; Thu, 11 Aug 2005 11:09:27 -0400 (EDT) To: David Leonard Cc: Jeffrey Hutzelman , sommerfeld@sun.com, ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> From: Sam Hartman Date: Thu, 11 Aug 2005 11:09:27 -0400 In-Reply-To: (David Leonard's message of "Thu, 11 Aug 2005 22:10:54 +1000 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list The handling of hostname canonicalization in GSSAPI is a thorny issue. The short answer is that you need to get a canonical hostname from the user or from secure DNS. Since you don't have secure DNS, you need it from the user. RFC 2743 and 2744 have somewhat outdated thinking on this point. While it is not a GSS spec, the discussion of this issue in RFC 4120 represents more current thinking. When appropriate data has been exchanged in advance, the application may perform this determination syntactically based on the application protocol specification, information provided by the user, and configuration files. For example, the server principal name (including realm) for a telnet server might be derived from the user-specified host name (from the telnet command line), the "host/" prefix specified in the application protocol specification, and a mapping to a Kerberos realm derived syntactically from the domain part of the specified hostname and information from the local Kerberos realms database. One can also rely on trusted third parties to make this determination, but only when the data obtained from the third party is suitably integrity-protected while resident on the third-party Neuman, et al. Standards Track [Page 9] RFC 4120 Kerberos V5 July 2005 server and when transmitted. Thus, for example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, accepting the primary name as the party that one intends to contact, since an attacker can modify the mapping and impersonate the party. Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). In an environment without secure name service, application authors MAY append a statically configured domain name to unqualified hostnames before passing the name to the security mechanisms, but they should do no more than that. Secure name service facilities, if available, might be trusted for hostname canonicalization, but such canonicalization by the client SHOULD NOT be required by KDC implementations. Implementation note: Many current implementations do some degree of canonicalization of the provided service name, often using DNS even though it creates security problems. However, there is no consistency among implementations as to whether the service name is case folded to lowercase or whether reverse resolution is used. To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user- entered name to lowercase without performing any other modifications or canonicalization. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 11 11:31:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3F1M-0005Gz-Kk for secsh-archive@megatron.ietf.org; Thu, 11 Aug 2005 11:31:05 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09521 for ; Thu, 11 Aug 2005 11:31:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3FF2E63B264; Thu, 11 Aug 2005 15:31:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8D9FC63B13E for ; Thu, 11 Aug 2005 15:31:00 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7754795; Thu, 11 Aug 2005 09:30:59 -0600 Message-ID: <42FB70EB.9010402@vandyke.com> Date: Thu, 11 Aug 2005 09:38:19 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Sam Hartman , sommerfeld@sun.com, David.Leonard@quest.com, ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> In-Reply-To: <7673A0F0198AF89468B0F982@bistromath.pc.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 Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > David Leonard wrote: >> Here are my comments about draft-ietf-secsh-gsskeyex-09.txt having >> worked with it to implement it in PuTTY a few weeks back. >> [...] >> * s3.7 "This packet should be sent ...": The word "should" be >> capitalized to clarify its meaning? > > Possibly. This text dates back to the original GSSAPI userauth draft, > so perhaps Joseph Galbraith can shed some light on whether he intended > this to have the force of requirements language. Hmmm... I think I agree it should be SHOULD. I.e., no one should be slipping in extra packets between SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE and SSH_MSG_USERAUTH_SUCCESS unless they have a darn good reason. I'm actually tempted to say it should be MUST-- but that might be a bit too strong when one considers SSH_MSG_IGNORE and SSH_MSG_DEBUG. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 11 12:13:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Fgf-0006tK-Q6 for secsh-archive@megatron.ietf.org; Thu, 11 Aug 2005 12:13:49 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11598 for ; Thu, 11 Aug 2005 12:13:42 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6D37963B27F; Thu, 11 Aug 2005 16:13:41 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 5037763B1EB for ; Thu, 11 Aug 2005 16:13:40 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa01577; 11 Aug 2005 12:13 EDT Received: from host212.lab.noc.kth.se (IDENT:U2FsdGVkX1/3jrADt1hmkM9dNWkN93+ZWqn7gP2Ezkk@host212.lab.noc.kth.se [193.11.23.212]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7BGDJaL013319 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 Aug 2005 12:13:21 -0400 (EDT) Date: Thu, 11 Aug 2005 18:13:18 +0200 From: Jeffrey Hutzelman To: Joseph Galbraith cc: Jeffrey Hutzelman , Sam Hartman , sommerfeld@sun.com, David.Leonard@quest.com, ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments Message-ID: <0FE2C54FA9A53AA0267D70DD@bistromath.pc.cs.cmu.edu> In-Reply-To: <42FB70EB.9010402@vandyke.com> References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <42FB70EB.9010402@vandyke.com> Originator-Info: login-token=Mulberry:01tMarpx4uIBsAESMo50TbFks44tI7+iQhO9kM6kY=; 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 Content-Transfer-Encoding: 7bit On Thursday, August 11, 2005 09:38:19 -0600 Joseph Galbraith wrote: > I think I agree it should be SHOULD. I.e., no one should be > slipping in extra packets between > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE and > SSH_MSG_USERAUTH_SUCCESS unless they have a darn good > reason. OK. I happen to agree, but wanted to make sure this was the original intent. > I'm actually tempted to say it should be MUST-- but > that might be a bit too strong when one considers > SSH_MSG_IGNORE and SSH_MSG_DEBUG. Agree. Fixed in the source. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 12 01:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Rpz-0004WQ-DS for secsh-archive@megatron.ietf.org; Fri, 12 Aug 2005 01:12:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19159 for ; Fri, 12 Aug 2005 01:12:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AE29863B31B; Fri, 12 Aug 2005 05:12:04 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id BE7E163B323 for ; Fri, 12 Aug 2005 05:12:03 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 330CD17E625; Fri, 12 Aug 2005 15:12:02 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 2BCC117E606; Fri, 12 Aug 2005 15:12:02 +1000 (EST) Date: Fri, 12 Aug 2005 15:12:02 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: <200508101638.MAA06045@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> <200508101638.MAA06045@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 10 Aug 2005, der Mouse wrote: > I've been told modern openssh does connection sharing - when I was at > BSDCan in May another person there showed me a manpage including an > option for it. Yes, for over a year now. Though the multiplexed X11 and agent support is more recent (CVS only). > Does anyone here know what they do about this issue, > how they deal with the "which session does this agent channel open go > with" question? If there's some way to do it with the stock request > and channel type, I'd very much like to know it - but I sure can't see > one; I think there simply isn't enough information. Correct, connection multiplexing in OpenSSH will share a single agent and/or X11 listener between all sessions forwarded over a single TCP connection. Apart from the lack of support[*] for forwarding multiple X or agent sockets in the protocol, I was concerned about users coming to depend on connection sharing to enforce sufficient separation between sessions with different privilege. In particular, the risk of timing attacks, etc. -d * it is entirely possible to forward multiple X11 sessions using the protocol as specified. You can use the fake X11 auth cookie to as a key, but of course it gets complicated if they collide and you need to make sure that they are long enough so as to be practically unguessable. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 12 01:31:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3S8s-00088w-Vi for secsh-archive@megatron.ietf.org; Fri, 12 Aug 2005 01:31:43 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19853 for ; Fri, 12 Aug 2005 01:31:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8737C63B325; Fri, 12 Aug 2005 05:31:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 7A88E63B2BA for ; Fri, 12 Aug 2005 05:31:37 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA06458; Fri, 12 Aug 2005 01:31:28 -0400 (EDT) From: der Mouse Message-Id: <200508120531.BAA06458@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 12 Aug 2005 01:23:16 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: what's left? In-Reply-To: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <200508090633.CAA16472@Sparkle.Rodents.Montreal.QC.CA> <200508091318.JAA17593@Sparkle.Rodents.Montreal.QC.CA> <385DCA310A222F9758B389B1@bistromath.pc.cs.cmu.edu> <200508091531.LAA18479@Sparkle.Rodents.Montreal.QC.CA> <200508101638.MAA06045@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Apart from the lack of support[*] for forwarding multiple X or agent > sockets in the protocol, I was concerned about users coming to depend > on connection sharing to enforce sufficient separation between > sessions with different privilege. In particular, the risk of timing > attacks, etc. As reasonable a concern as that is in general, I have trouble getting worried about it when the two conceptual connections are perforce authenticated as not only the same user, but with the same authentication method and data. I have even more trouble getting worried about it with respect to agent and X forwarding when waving off the same issues as they apply to ordinary data flow (necessarily; there is no choice about this when doing connection sharing, unless you're prepared to do some kind of traffic shaping on the sub-connections, which is Hard given the ignorance the ssh code generally has of the underlying network characteristics). Perhaps this just reflects a difference in our target audiences, or more precisely in the threat models that are lurking in our minds when we make choices like these. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 12 15:50:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3fXg-0001Au-HW for secsh-archive@megatron.ietf.org; Fri, 12 Aug 2005 15:50:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15131 for ; Fri, 12 Aug 2005 15:50:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6E2F463B2EF; Fri, 12 Aug 2005 19:50:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 8157463B134 for ; Fri, 12 Aug 2005 19:50:05 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E3fXW-0004Gq-HQ; Fri, 12 Aug 2005 15:50:02 -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-dh-group-exchange-05.txt Message-Id: Date: Fri, 12 Aug 2005 15:50:02 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol Author(s) : M. Friedl, et al. Filename : draft-ietf-secsh-dh-group-exchange-05.txt Pages : 9 Date : 2005-8-12 This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-05.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-dh-group-exchange-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-12124926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dh-group-exchange-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-12124926.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 12 16:15:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3fw8-0004d7-Sd for secsh-archive@megatron.ietf.org; Fri, 12 Aug 2005 16:15:29 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22689 for ; Fri, 12 Aug 2005 16:15:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9ADFB63B30F; Fri, 12 Aug 2005 20:15:24 +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 00E4363B134 for ; Fri, 12 Aug 2005 20:15:23 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7CKFNvU015496 for ; Fri, 12 Aug 2005 14:15:23 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7CKFMlM025698; Fri, 12 Aug 2005 16:15:23 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7CKFM19022107; Fri, 12 Aug 2005 16:15:22 -0400 (EDT) Subject: Re: I-D ACTION:draft-ietf-secsh-dh-group-exchange-05.txt From: Bill Sommerfeld To: ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1123877721.19766.289.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 12 Aug 2005 16:15:22 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-08-12 at 15:50, Internet-Drafts@ietf.org wrote: > Title : Diffie-Hellman Group Exchange for the SSH > Transport Layer Protocol > Author(s) : M. Friedl, et al. > Filename : draft-ietf-secsh-dh-group-exchange-05.txt > Pages : 9 > Date : 2005-8-12 as a reminder, this document is undergoing IESG review; this has been rev'ed specifically to address DISCUSS comments from the IESG. see: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6503&rfc_flag=0 for details. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 12 19:46:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3jEE-0002sx-Jq for secsh-archive@megatron.ietf.org; Fri, 12 Aug 2005 19:46:23 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11035 for ; Fri, 12 Aug 2005 19:46:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 530E863B354; Fri, 12 Aug 2005 23:46:15 +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 99C6763B11F for ; Fri, 12 Aug 2005 23:46:14 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7CNkCvU005996; Fri, 12 Aug 2005 17:46:12 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7CNkAlM006572; Fri, 12 Aug 2005 19:46:11 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7CNkAJE022785; Fri, 12 Aug 2005 19:46:10 -0400 (EDT) Subject: Re: Agent IPR issues (was Re: Secure Shell WG: what's left?) From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: dtucker@zip.com.au, ietf-ssh@NetBSD.org In-Reply-To: References: <1123546167.29244.159.camel@thunk> <200508090140.VAA05199@Sparkle.Rodents.Montreal.QC.CA> <20050810100052.GA12527@gate.dodgy.net.au> Content-Type: text/plain Message-Id: <1123890369.19766.578.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 12 Aug 2005 19:46:10 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-08-10 at 06:48, Jeffrey Hutzelman wrote: > At the time that draft was written, the text you quoted was the standard > boilerplate to be used when an IPR claim had been received that was alleged > or believed to apply to that document. Since then, I believe the > boilerplate has been changed such that it doesn't say whether there is a > specific claim related to this document, consistent with the IETF's policy > of not taking positions wrt IPR claims. I believe the "there are IPR claims" notice was added due to the trademark issue. > > No IPR disclosures related to draft-ietf-secsh-agent have been > > submitted To my knowledge, no IPR disclosures related to the trademark were ever filed. The IETF IPR disclosure process has subsequently been made patent-specific. > I did rather more searches than that, and I couldn't come up with anything, > either. As of shortly before the core drafts were approved, the ietf process for trademark references was fixed to permit documents to reference the registration authority for a claimed trademark. This is generally necessary only when a listed author/contributor is the trademark registrant or is bound by an agreement with the trademark registrant to identify that a word is trademarked. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Aug 14 02:04:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4BbR-0007JJ-Le for secsh-archive@megatron.ietf.org; Sun, 14 Aug 2005 02:04:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02658 for ; Sun, 14 Aug 2005 02:04:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7DD1063B338; Sun, 14 Aug 2005 06:03:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fork.recoil.org (fork.recoil.org [194.70.3.132]) by mail.netbsd.org (Postfix) with SMTP id B4ED663B336 for ; Sun, 14 Aug 2005 06:03:51 +0000 (UTC) Received: (qmail 14170 invoked by uid 10000); 14 Aug 2005 06:03:50 -0000 Date: Sun, 14 Aug 2005 07:03:50 +0100 From: Anil Madhavapeddy To: ietf-ssh@NetBSD.org Subject: nit in draft-ietf-secsh-connect-25.txt Message-ID: <20050814060350.GA24486@fork.recoil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Sender: ietf-ssh-owner@NetBSD.org Precedence: list In Section 6.10 (Returning Exit Status) of draft-ietf-secsh-connect-25.txt, the formatting of the "exit-signal" packet is different from the rest and indented incorrectly. Breaks my spec-extraction regexp, hence the motivation to point it out :) -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 15 08:19:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4dvr-0006rG-LZ for secsh-archive@megatron.ietf.org; Mon, 15 Aug 2005 08:19:11 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29536 for ; Mon, 15 Aug 2005 08:19:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9A84863B1C0; Mon, 15 Aug 2005 12:18:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 0349863B10C for ; Mon, 15 Aug 2005 12:18:57 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2005 05:17:55 -0700 X-IronPort-AV: i="3.96,107,1122879600"; d="scan'208"; a="654746581:sNHT28005528" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7FCHrop017514; Mon, 15 Aug 2005 05:17:54 -0700 (PDT) Date: Mon, 15 Aug 2005 05:17:53 -0700 (PDT) From: Chris Lonvick To: Anil Madhavapeddy cc: ietf-ssh@NetBSD.org Subject: Re: nit in draft-ietf-secsh-connect-25.txt In-Reply-To: <20050814060350.GA24486@fork.recoil.org> Message-ID: References: <20050814060350.GA24486@fork.recoil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Anil, On Sun, 14 Aug 2005, Anil Madhavapeddy wrote: > In Section 6.10 (Returning Exit Status) of draft-ietf-secsh-connect-25.txt, > the formatting of the "exit-signal" packet is different from the > rest and indented incorrectly. Breaks my spec-extraction regexp, > hence the motivation to point it out :) > > -- > Anil Madhavapeddy http://anil.recoil.org > University of Cambridge http://www.cl.cam.ac.uk > That was noted and corrected several months ago. The IDs are now in the RFC Editors queue so it's not appropriate to re-spin them. I'm maintaining the list of nits here: http://www.employees.org/~lonvick/secsh-wg/2005-april-6/lastnits and I've let the RFC Editor know that the documents with the corrections are here: http://www.employees.org/~lonvick/secsh-wg/2005-april-6/ The differences in indentations are mostly due to the xml. When a 'list' was used, usually because of a reference in one or more of the lines, then it is automatically indented. When 'artwork' is used then the indentation is manual. I'll look into straightening them out. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 15 15:13:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kON-0005zJ-C8 for secsh-archive@megatron.ietf.org; Mon, 15 Aug 2005 15:13:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20750 for ; Mon, 15 Aug 2005 15:13:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2444463B499; Mon, 15 Aug 2005 19:12:45 +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 547DF63B49A for ; Mon, 15 Aug 2005 19:12:44 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7FJChte020336; Mon, 15 Aug 2005 12:12:43 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7FJChUj003795; Mon, 15 Aug 2005 15:12:43 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7FJCgOE002953; Mon, 15 Aug 2005 15:12:42 -0400 (EDT) Subject: Re: nit in draft-ietf-secsh-connect-25.txt From: Bill Sommerfeld To: Anil Madhavapeddy Cc: ietf-ssh@NetBSD.org In-Reply-To: <20050814060350.GA24486@fork.recoil.org> References: <20050814060350.GA24486@fork.recoil.org> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1124133162.2344.8.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 15 Aug 2005 15:12:42 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Sun, 2005-08-14 at 02:03, Anil Madhavapeddy wrote: > In Section 6.10 (Returning Exit Status) of draft-ietf-secsh-connect-25.txt, > the formatting of the "exit-signal" packet is different from the > rest and indented incorrectly. Breaks my spec-extraction regexp, > hence the motivation to point it out :) Thank you for checking for this. The construction and use of automated tools to parse and syntax-check specification languages in ietf specs is encouraged by the IESG. See: http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt The packet-format description language used in the ssh specs is.. minimalist so I imagine there isn't much to your regexps. but every little bit helps. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 17 18:27:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WNm-00031D-J2 for secsh-archive@megatron.ietf.org; Wed, 17 Aug 2005 18:27:40 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07993 for ; Wed, 17 Aug 2005 18:27:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 21EEE63B1DA; Wed, 17 Aug 2005 22:27:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by mail.netbsd.org (Postfix) with ESMTP id 5682363B11D for ; Wed, 17 Aug 2005 22:27:31 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from libra.cus.cam.ac.uk ([131.111.8.19]:55366) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1E5WNc-0004o5-2y (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Wed, 17 Aug 2005 23:27:28 +0100 Received: from bjh21 (helo=localhost) by libra.cus.cam.ac.uk with local-esmtp (Exim 4.52) id 1E5WNc-0003Mn-KD for ietf-ssh@netbsd.org; Wed, 17 Aug 2005 23:27:28 +0100 Date: Wed, 17 Aug 2005 23:27:28 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: draft-harris-ssh-rsa-kex-04 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Yet another version of my RSA KEX draft has hit the I-D repository. It fixes the order of keys in the PUBKEY packet and adds some discussion of collision attacks to the security considerations. If there's anything that needs changing before I move the algorithm names into the IETF namespace and send the document off to the IESG, now's the time to tell me. I propose to send it to the IESG as an individual submission to the Standards Track. People should tell me if they think I shouldn't do that. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 17 18:48:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Whu-0008AO-85 for secsh-archive@megatron.ietf.org; Wed, 17 Aug 2005 18:48:26 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09467 for ; Wed, 17 Aug 2005 18:48:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A6DF63B1A4; Wed, 17 Aug 2005 22:48:22 +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 9D2D863B11D for ; Wed, 17 Aug 2005 22:48:21 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7HMmL2B025261 for ; Wed, 17 Aug 2005 15:48:21 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7HMmKWB022421; Wed, 17 Aug 2005 18:48:20 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7HMmKST020524; Wed, 17 Aug 2005 18:48:20 -0400 (EDT) Subject: Re: Secure Shell: Milestone Update. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org In-Reply-To: <5414F45ED18E016712F63D63@sirius.fac.cs.cmu.edu> References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> <871xadinlv.fsf@luminous.mit.edu> <5414F45ED18E016712F63D63@sirius.fac.cs.cmu.edu> Content-Type: text/plain Message-Id: <1124318900.17138.209.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 17 Aug 2005 18:48:20 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit we had an extended discussion on updating the milestones back in March, and then I failed to officially update them. Here's what I plan to send in: DELETE: Drop Agent draft ready for last call (unless someone steps up to own this draft ...) ADD DONE (March 05) IESG approval of core drafts Update: Aug 05 publickeyfile ready for last call Aug 05 public key format ready for last call Sep 05 URI draft ready for last call Oct 05 File transfer draft ready for last call Oct 05 X.509v3/pkix draft ready for last call Nov 05 Investigate Draft Standard status for secure shell - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 18 02:32:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5dxD-00085h-7u for secsh-archive@megatron.ietf.org; Thu, 18 Aug 2005 02:32:43 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14096 for ; Thu, 18 Aug 2005 02:32:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id ED3C263B158; Thu, 18 Aug 2005 06:32:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 46F9263B138 for ; Thu, 18 Aug 2005 06:32:37 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 0E5D2503AB; Thu, 18 Aug 2005 08:13:23 +0200 (CEST) Message-ID: <43042717.7070307@siliconcircus.com> Date: Thu, 18 Aug 2005 08:13:43 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> <871xadinlv.fsf@luminous.mit.edu> <5414F45ED18E016712F63D63@sirius.fac.cs.cmu.edu> <1124318900.17138.209.camel@thunk> In-Reply-To: <1124318900.17138.209.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > Update: > > Aug 05 publickeyfile ready for last call > Aug 05 public key format ready for last call Was one of these perhaps supposed to be public key subsystem? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 18 10:54:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lmN-0007kM-Ey for secsh-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:54:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10857 for ; Thu, 18 Aug 2005 10:54:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9DFC963B252; Thu, 18 Aug 2005 14:53:56 +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 000B163B249 for ; Thu, 18 Aug 2005 14:53:55 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7IErsWR002554; Thu, 18 Aug 2005 08:53:55 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7IErsWB015189; Thu, 18 Aug 2005 10:53:54 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7IErsYG008879; Thu, 18 Aug 2005 10:53:54 -0400 (EDT) Subject: Re: Secure Shell: Milestone Update. From: Bill Sommerfeld To: Jon Bright Cc: ietf-ssh@NetBSD.org In-Reply-To: <43042717.7070307@siliconcircus.com> References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> <871xadinlv.fsf@luminous.mit.edu> <5414F45ED18E016712F63D63@sirius.fac.cs.cmu.edu> <1124318900.17138.209.camel@thunk> <43042717.7070307@siliconcircus.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1124376833.8856.0.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 18 Aug 2005 10:53:54 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-08-18 at 02:13, Jon Bright wrote: > Bill Sommerfeld wrote: > > > > Update: > > > > Aug 05 publickeyfile ready for last call > > Aug 05 public key format ready for last call > > Was one of these perhaps supposed to be public key subsystem? err, yes. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 18 18:20:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5skl-0005XJ-UI for secsh-archive@megatron.ietf.org; Thu, 18 Aug 2005 18:20:51 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07868 for ; Thu, 18 Aug 2005 18:20:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C979A63B2C6; Thu, 18 Aug 2005 22:20:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 2F37563B2B3 for ; Thu, 18 Aug 2005 22:20:46 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 18 Aug 2005 15:20:46 -0700 X-IronPort-AV: i="3.96,123,1122879600"; d="scan'208"; a="655523542:sNHT27350568" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7IMKcos011464 for ; Thu, 18 Aug 2005 15:20:44 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: SFTP server newline convention X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 18 Aug 2005 15:25:31 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C06323@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: SFTP server newline convention Thread-Index: AcWkQxGuiXa4WoH2QzepLOb6nful3w== From: "Salowey, Joe" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable In reading draft-ietf-secsh-filexfer-09.txt it seems that the newline extension is for the server to tell the client what the newline convention is for text files. This then puts the burden of newline conversion on the client instead of the server if the canonical newline character sequences differ. Am I interpreting this correctly? If this is the case then it doesn't seem like it makes sense to be able to specify the canonical newline indicator in the SFTP URI since this is a server specified parameter and I can remove the parameter from the current draft. =20 Thanks, Joe From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 18 19:59:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5uI5-0006aK-97 for secsh-archive@megatron.ietf.org; Thu, 18 Aug 2005 19:59:21 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17751 for ; Thu, 18 Aug 2005 19:59:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6CB1D63B2BA; Thu, 18 Aug 2005 23:59:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id BE1A763B127 for ; Thu, 18 Aug 2005 23:59:15 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7789043; Thu, 18 Aug 2005 17:59:14 -0600 Message-ID: <4305229F.4020109@vandyke.com> Date: Thu, 18 Aug 2005 18:06:55 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: "Salowey, Joe" CC: ietf-ssh@NetBSD.org Subject: Re: SFTP server newline convention References: <7210B31550AC934A8637D6619739CE6905C06323@e2k-sea-xch2.sea-alpha.cisco.com> In-Reply-To: <7210B31550AC934A8637D6619739CE6905C06323@e2k-sea-xch2.sea-alpha.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Salowey, Joe wrote: > In reading draft-ietf-secsh-filexfer-09.txt it seems that the newline > extension is for the server to tell the client what the newline > convention is for text files. This then puts the burden of newline > conversion on the client instead of the server if the canonical newline > character sequences differ. Am I interpreting this correctly? Yes. > If this is the case then it doesn't seem like it makes sense to be able > to specify the canonical newline indicator in the SFTP URI since this is > a server specified parameter and I can remove the parameter from the > current draft. I believe this is the case. When a file is opened in TEXT mode, the newline indicator is either: a. Whatever the server specified in the newline extension b. CRLF if the server didn't send a newline extension (However, none of this applies if the file isn't opened in TEXT mode-- if the file isn't opened in text mode, it probably uses whatever newline convention the server sent, but the server isn't canonicalizing.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 19 02:32:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E60Qp-0006ta-2y for secsh-archive@megatron.ietf.org; Fri, 19 Aug 2005 02:32:49 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15716 for ; Fri, 19 Aug 2005 02:32:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CD0CA63B25F; Fri, 19 Aug 2005 06:32:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id C1B6063B235 for ; Fri, 19 Aug 2005 06:32:39 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa24774; 19 Aug 2005 0:32 EDT Date: Fri, 19 Aug 2005 00:32:03 -0400 From: Jeffrey Hutzelman To: David Leonard cc: Sam Hartman , sommerfeld@sun.com, ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments Message-ID: In-Reply-To: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:01h1qaa/HCD9/TpRLsutjK2h7M0ZYOjhP0z8jQvdo=; 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 Content-Transfer-Encoding: 7bit On Thursday, August 11, 2005 10:10:54 PM +1000 David Leonard wrote: >> > * s7.1 In the last phrase "the hostname of the SSH server": Sometimes >> > users specify IP addresses instead of hostnames, and the GSS >> > mechanism is expected to deal with it (rightly so). Now, my concern >> > is with the use of the word 'hostname' in the case of targets >> > specified as network addresses. As written the par seems to imply a >> > client ought to do reverse DNS if an IP address is given. So I >> > suggest changing "the hostname of the SSH server" to "the given name >> > of the SSH server" or something like that. >> >> I believe the existing text is correct. The construction of GSSAPI >> host-based service names requires a hostname, not an IP address. Yes, >> that means that if the user provides an IP address, the server will need >> to reverse-resolve in a secure fashion. > > No. I read RFC2743 s4.1 to say that the canonicalizing of the "hostname" > string is the job of the GSS mechanism, and not that of the SSH server > code. > > If you agree, then I think a better correction is to just quote the word > "hostname" in the last sentence of s7.1, as was done in rfc2743 s4.1. RFC2743's use of quotes there indicates that it is talking about a field called "hostname". The quotes are not derisive, and are not intended to suggest that that field is populated with something other than what is normally meant by that word. Unfortunately, RFC2743 is rather outdated in this respect, as well as in some others, and in some cases it is also unclear. I believe Sam has adequately explained the current thinking among people working on GSSAPI regarding hostname canonicaliation. I expect this issue to be explained rather more clearly in an upcoming revision of the GSSAPI spec. In the meantime, I still believe the wording in the present document says what we intended, and does not require any changes. I have been asked to submit an updated version of this document within the next few days, in order to get it on the agenda for the September 1 IESG telechat. Unless Bill finds that we have consensus for a change in this area, I will submit the draft early next week with no further changes. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 19 15:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CsT-0004JB-9H for secsh-archive@megatron.ietf.org; Fri, 19 Aug 2005 15:50:09 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25897 for ; Fri, 19 Aug 2005 15:50:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A3B3B63B311; Fri, 19 Aug 2005 19:50:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id AE34E63B2CE for ; Fri, 19 Aug 2005 19:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E6CsM-0002gl-5V; Fri, 19 Aug 2005 15:50:02 -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-newmodes-05.txt Message-Id: Date: Fri, 19 Aug 2005 15:50:02 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Encryption Modes Author(s) : M. Bellare, et al. Filename : draft-ietf-secsh-newmodes-05.txt Pages : 12 Date : 2005-8-19 Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. In a paper at the Ninth ACM Conference on Computer and Communications Security, Bellare, Kohno, and Namprempre prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy, and integrity/authenticity attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.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-newmodes-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-newmodes-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-19141702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-newmodes-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-newmodes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-19141702.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 20 13:39:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6XJz-0006Au-R7 for secsh-archive@megatron.ietf.org; Sat, 20 Aug 2005 13:39:55 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00843 for ; Sat, 20 Aug 2005 13:39:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D5C4863B386; Sat, 20 Aug 2005 17:39:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from kiskaddon.com (kiskaddon.com [130.94.219.214]) by mail.netbsd.org (Postfix) with ESMTP id 5704E63B110 for ; Sat, 20 Aug 2005 17:39:47 +0000 (UTC) Received: (qmail 33501 invoked by uid 23510); 20 Aug 2005 17:33:07 -0000 Delivered-To: info@kiskaddon.com Message-ID: <20050820173307.33500.qmail@kiskaddon.com> Date: 20 Aug 2005 17:33:07 -0000 From: info@kiskaddon.com To: ietf-ssh@NetBSD.org Subject: [Auto-Reply] Re: Old times MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: qmail-reply (by qmail-ldap) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Your message has been received into our email system and will be forwarded to our staff. Thank you, for your interest. Kiskaddon Architects, PLC From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 01:54:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E75Gp-0002Mj-Sg for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 01:54:58 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10364 for ; Mon, 22 Aug 2005 01:54:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9559B63B208; Mon, 22 Aug 2005 05:54:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6EB6063B1EA for ; Mon, 22 Aug 2005 05:54:37 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA25940; Mon, 22 Aug 2005 01:54:30 -0400 (EDT) From: der Mouse Message-Id: <200508220554.BAA25940@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 22 Aug 2005 01:52:21 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-04 In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Yet another version of my RSA KEX draft has hit the I-D repository. > It fixes the order of keys in the PUBKEY packet and adds some > discussion of collision attacks to the security considerations. If > there's anything that needs changing before I move the algorithm > names into the IETF namespace and send the document off to the IESG, > now's the time to tell me. Typo fix: before it has seen the client's choice of K. The clients last input s/clients/client's/ Other than that, it looks fine to me. I haven't yet implemented it, but I intend to; it should be fairly simple. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 11:14:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E0Y-0003Zc-Km for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 11:14:42 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21886 for ; Mon, 22 Aug 2005 11:14:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 71EB263B462; Mon, 22 Aug 2005 15:14:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 93C5463B458 for ; Mon, 22 Aug 2005 15:14:32 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7796097; Mon, 22 Aug 2005 09:14:31 -0600 Message-ID: <4309EDAE.6000303@vandyke.com> Date: Mon, 22 Aug 2005 09:22:22 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Please publish the attached draft-ietf-secsh-publickeyfile-09.txt Content-Type: multipart/mixed; boundary="------------070002060202060204080103" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------070002060202060204080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please publish the attached draft-ietf-secsh-publickeyfile-09.txt Thanks, Joseph --------------070002060202060204080103 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-09.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickeyfile-09.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: February 23, 2006 R. Thayer The Tillerman Group August 22, 2005 SSH Public Key File Format draft-ietf-secsh-publickeyfile-09.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 February 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. Galbraith & Thayer Expires February 23, 2006 [Page 1] Internet-Draft SSH Public Key File Format August 2005 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 3.3.3. New Headers . . . . . . . . . . . . . . . . . . . . . 6 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Galbraith & Thayer Expires February 23, 2006 [Page 2] Internet-Draft SSH Public Key File Format August 2005 1. Conventions used in this document 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]. Galbraith & Thayer Expires February 23, 2006 [Page 3] Internet-Draft SSH Public Key File Format August 2005 2. Introduction In order to use public key authentication, public keys must be exchanged between client and server. This document formally describes an existing public key file format. Galbraith & Thayer Expires February 23, 2006 [Page 4] Internet-Draft SSH Public Key File Format August 2005 3. Key File Format In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 bytes excluding line termination characters. 3.1. Line Termination Characters Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . 3.2. Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3. Key File Header The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 bytes, and is case- insensitive. The Header-value MUST NOT be more than 1024 bytes. Each line in the header MUST NOT be more than 72 bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and the line termination characters, and appending the contents of the next line. The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be Galbraith & Thayer Expires February 23, 2006 [Page 5] Internet-Draft SSH Public Key File Format August 2005 encoded in UTF-8. [RFC3629] A line that is not a continuation line that has no ':' in it is the first line of the base 64 encoded body (See Section 3.4.) Compliant implementations MUST ignore unrecognized header fields. Implementations SHOULD preserve unrecognized header fields when manipulating the key file. 3.3.1. Subject Header This field is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2. Comment Header The comment header contains a user specified comment. The comment SHOULD be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@example.com Currently, common practice is to quote the Header-value of the Comment by prefixing and suffixing it with '"' characters, and some existing implementations fail if these quotation marks are omitted Compliant implementations MUST function correctly if the quotation marks are omitted. Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching quotation marks, implementations SHOULD remove them before using the value. 3.3.3. New Headers New headers that are of the from "x-" are considered experimental, and may be used without IETF consensus. All other headers are reserved for use only by IETF consensus. 3.4. Public Key File Body The body of a public key file consists of the public key blob as described in [I-D.ietf-secsh-transport], section 4.6, "Public Key Galbraith & Thayer Expires February 23, 2006 [Page 6] Internet-Draft SSH Public Key File Format August 2005 Algorithms", encoded in base 64 as specified in [RFC2045], section 6.8, "Base64 Content-Transfer-Encoding". As with all other lines, each line in the body MUST NOT be longer than 72 characters excluding line termination characters. 3.5. Differences with RFC1421 PEM formats Implemetors should take care to notice that while the format is superficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably: o The other specifications use different BEGIN/END delimeters (five dashes, no space rather than four dashes and a space). o There is no blank line before the start of the base64-encoded contents. o There is no CRC at the end of the base64-encoded block. o Header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. 3.6. Examples The following are some example public key files that are compliant (note that the examples all wrap before 72 lines to meet ietf document requirements; however, they are still compliant.) ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by me@myhost" x-command: /home/galb/bin/lock-in-guest.sh AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires February 23, 2006 [Page 7] Internet-Draft SSH Public Key File Format August 2005 ---- BEGIN SSH2 PUBLIC KEY ---- Comment: This is my public key for use on \ servers which I don't like. AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by me@myhost Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires February 23, 2006 [Page 8] Internet-Draft SSH Public Key File Format August 2005 4. Public Key Fingerprints The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community. The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC1321]. The input to the algorithm is the public key blob as described in [I-D.ietf-secsh-transport]. The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" Galbraith & Thayer Expires February 23, 2006 [Page 9] Internet-Draft SSH Public Key File Format August 2005 5. IANA Considerations There are no IANA registries or other considerations associated with this document. Galbraith & Thayer Expires February 23, 2006 [Page 10] Internet-Draft SSH Public Key File Format August 2005 6. Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. The public-key fingerprint method presented here relies on the MD5 hash, which is known to have certain weaknesses. The use of it here is for historical purposes, and the particular use made of it depends solely one it's 2nd-preimage resistance, not on it's collision- resistance. Galbraith & Thayer Expires February 23, 2006 [Page 11] Internet-Draft SSH Public Key File Format August 2005 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [I-D.ietf-secsh-transport] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. 7.2. Informative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. Galbraith & Thayer Expires February 23, 2006 [Page 12] Internet-Draft SSH Public Key File Format August 2005 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 Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 Email: rodney@tillerman.to Galbraith & Thayer Expires February 23, 2006 [Page 13] Internet-Draft SSH Public Key File Format August 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Thayer Expires February 23, 2006 [Page 14] --------------070002060202060204080103-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 11:19:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E5e-0004hr-94 for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 11:19:58 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22295 for ; Mon, 22 Aug 2005 11:19:55 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7EDB863B461; Mon, 22 Aug 2005 15:19:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id DFCFA63B458 for ; Mon, 22 Aug 2005 15:19:54 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7796135; Mon, 22 Aug 2005 09:19:54 -0600 Message-ID: <4309EEF1.1090501@vandyke.com> Date: Mon, 22 Aug 2005 09:27:45 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Ouadah Farid CC: ietf-ssh@NetBSD.org Subject: Re: filexfer-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Thanks; I've taken care of both these things. Joseph Ouadah Farid wrote: > Hello, > > I suggest those modifications: > > 3.1 > > A client MUST be prepared to recieve responses to multiple overlapped > requests out of order. > > recieve => receive > > 4.5 > > extension-count > Count of extension names in the attrib-extension array. > > The definition is the same as attrib-extension-count. > > > Farid. > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 11:21:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E7H-000535-13 for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 11:21:39 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22423 for ; Mon, 22 Aug 2005 11:21:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 24CA063B464; Mon, 22 Aug 2005 15:21:36 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 71C8763B458 for ; Mon, 22 Aug 2005 15:21:35 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7796151; Mon, 22 Aug 2005 09:21:34 -0600 Message-ID: <4309EF55.3080409@vandyke.com> Date: Mon, 22 Aug 2005 09:29:25 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 CC: Sara Golemon , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-filexfer Change to rename op in version 5 References: <00a501c5736d$623ecec0$5c8be5a9@ohr.berkeley.edu> <42C56CAF.2070204@vandyke.com> In-Reply-To: <42C56CAF.2070204@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > Sara Golemon wrote: >> I got tripped up by some vague wording in the changelog covering >> differences >> between version 4 and version 5, specifically: >> >> o Add support for better control of the rename operation. >> >> >> After looking through implementation sources, I found that this refers to >> the addition of the flags parameter to FXP_RENAME. >> >> byte SSH_FXP_RENAME >> uint32 request-id >> string oldpath [UTF-8] >> string newpath [UTF-8] >> uint32 flags >> >> To avoid others being confused by this I'd like to propose a change to >> the >> changelog entry's wording: >> >> o Add flags parameter to the rename operation to control rename >> behavior. > > I'll make this change... I've now made this change-- expect a new document shortly. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 13:58:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GZQ-0004NI-16 for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:58:52 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01242 for ; Mon, 22 Aug 2005 13:58:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 626FB63B47E; Mon, 22 Aug 2005 17:58:46 +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 7444963B1E4 for ; Mon, 22 Aug 2005 17:58:45 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7MHwRTW019991; Mon, 22 Aug 2005 11:58:27 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7MHwPWB027332; Mon, 22 Aug 2005 13:58:25 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7MHwPDT028232; Mon, 22 Aug 2005 13:58:25 -0400 (EDT) Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: David Leonard , Sam Hartman , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov In-Reply-To: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> Content-Type: text/plain Message-Id: <1124733504.24824.191.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 22 Aug 2005 13:58:25 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-08-19 at 00:32, Jeffrey Hutzelman wrote: > I have been asked to submit an updated version of this document within the > next few days, in order to get it on the agenda for the September 1 IESG > telechat. Unless Bill finds that we have consensus for a change in this > area, I will submit the draft early next week with no further changes. I've reviewed the messages exchanged so far on this issue. I see what looks like consensus that there's a hole in the spec: the spec as it stands is silent on what an implementation should do if a hostname is not available. IMHO, the main thing that matters for interoperability is the complete client system behavior rather than the behavior of the part of the system which is above the GSS *API* boundary. Given that this question is being looked at within GSSAPI, perhaps the best we can say for now is that if a client system implementing this specification is unable to securely determine which hostname and/or GSS target name to use, then it SHOULD NOT use this mechanism. If the GSS API is later enhanced to provide a secure address->hostname translation function, then *this spec* does not need to be revised to account for this change. Comments? - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 15:27:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HxU-0005Kf-HD for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:27:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07659 for ; Mon, 22 Aug 2005 15:27:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 23FED63B20B; Mon, 22 Aug 2005 19:27:42 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id A3C5C63B189 for ; Mon, 22 Aug 2005 19:27:39 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7797001; Mon, 22 Aug 2005 13:27:38 -0600 Message-ID: <430A2902.8050103@vandyke.com> Date: Mon, 22 Aug 2005 13:35:30 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Please publish the attached draft-ietf-secsh-publickeyfile-09.txt Content-Type: multipart/mixed; boundary="------------060505050800090008010400" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------060505050800090008010400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please publish the attached draft-ietf-secsh-publickeyfile-09.txt Thanks, Joseph --------------060505050800090008010400 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-09.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickeyfile-09.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: February 23, 2006 R. Thayer The Tillerman Group August 22, 2005 SSH Public Key File Format draft-ietf-secsh-publickeyfile-09.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 February 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. Galbraith & Thayer Expires February 23, 2006 [Page 1] Internet-Draft SSH Public Key File Format August 2005 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 3.3.3. New Headers . . . . . . . . . . . . . . . . . . . . . 6 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Galbraith & Thayer Expires February 23, 2006 [Page 2] Internet-Draft SSH Public Key File Format August 2005 1. Conventions used in this document 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]. Galbraith & Thayer Expires February 23, 2006 [Page 3] Internet-Draft SSH Public Key File Format August 2005 2. Introduction In order to use public key authentication, public keys must be exchanged between client and server. This document formally describes an existing public key file format. Galbraith & Thayer Expires February 23, 2006 [Page 4] Internet-Draft SSH Public Key File Format August 2005 3. Key File Format In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 bytes excluding line termination characters. 3.1. Line Termination Characters Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . 3.2. Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3. Key File Header The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 bytes, and is case- insensitive. The Header-value MUST NOT be more than 1024 bytes. Each line in the header MUST NOT be more than 72 bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and the line termination characters, and appending the contents of the next line. The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be Galbraith & Thayer Expires February 23, 2006 [Page 5] Internet-Draft SSH Public Key File Format August 2005 encoded in UTF-8. [RFC3629] A line that is not a continuation line that has no ':' in it is the first line of the base 64 encoded body (See Section 3.4.) Compliant implementations MUST ignore unrecognized header fields. Implementations SHOULD preserve unrecognized header fields when manipulating the key file. 3.3.1. Subject Header This field is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2. Comment Header The comment header contains a user specified comment. The comment SHOULD be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@example.com Currently, common practice is to quote the Header-value of the Comment by prefixing and suffixing it with '"' characters, and some existing implementations fail if these quotation marks are omitted Compliant implementations MUST function correctly if the quotation marks are omitted. Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching quotation marks, implementations SHOULD remove them before using the value. 3.3.3. New Headers New headers that are of the from "x-" are considered experimental, and may be used without IETF consensus. All other headers are reserved for use only by IETF consensus. 3.4. Public Key File Body The body of a public key file consists of the public key blob as described in [I-D.ietf-secsh-transport], section 4.6, "Public Key Galbraith & Thayer Expires February 23, 2006 [Page 6] Internet-Draft SSH Public Key File Format August 2005 Algorithms", encoded in base 64 as specified in [RFC2045], section 6.8, "Base64 Content-Transfer-Encoding". As with all other lines, each line in the body MUST NOT be longer than 72 characters excluding line termination characters. 3.5. Differences with RFC1421 PEM formats Implemetors should take care to notice that while the format is superficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably: o The other specifications use different BEGIN/END delimeters (five dashes, no space rather than four dashes and a space). o There is no blank line before the start of the base64-encoded contents. o There is no CRC at the end of the base64-encoded block. o Header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. 3.6. Examples The following are some example public key files that are compliant (note that the examples all wrap before 72 lines to meet ietf document requirements; however, they are still compliant.) ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by me@myhost" x-command: /home/galb/bin/lock-in-guest.sh AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires February 23, 2006 [Page 7] Internet-Draft SSH Public Key File Format August 2005 ---- BEGIN SSH2 PUBLIC KEY ---- Comment: This is my public key for use on \ servers which I don't like. AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by me@myhost Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires February 23, 2006 [Page 8] Internet-Draft SSH Public Key File Format August 2005 4. Public Key Fingerprints The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community. The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC1321]. The input to the algorithm is the public key blob as described in [I-D.ietf-secsh-transport]. The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" Galbraith & Thayer Expires February 23, 2006 [Page 9] Internet-Draft SSH Public Key File Format August 2005 5. IANA Considerations There are no IANA registries or other considerations associated with this document. Galbraith & Thayer Expires February 23, 2006 [Page 10] Internet-Draft SSH Public Key File Format August 2005 6. Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. The public-key fingerprint method presented here relies on the MD5 hash, which is known to have certain weaknesses. The use of it here is for historical purposes, and the particular use made of it depends solely one it's 2nd-preimage resistance, not on it's collision- resistance. Galbraith & Thayer Expires February 23, 2006 [Page 11] Internet-Draft SSH Public Key File Format August 2005 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [I-D.ietf-secsh-transport] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. 7.2. Informative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. Galbraith & Thayer Expires February 23, 2006 [Page 12] Internet-Draft SSH Public Key File Format August 2005 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 Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 Email: rodney@tillerman.to Galbraith & Thayer Expires February 23, 2006 [Page 13] Internet-Draft SSH Public Key File Format August 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Thayer Expires February 23, 2006 [Page 14] --------------060505050800090008010400-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 15:50:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IJa-0000Ka-Fk for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:50:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08510 for ; Mon, 22 Aug 2005 15:50:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E895263B496; Mon, 22 Aug 2005 19:50:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from foretec.com (furball.foretec.com [132.151.15.110]) by mail.netbsd.org (Postfix) with ESMTP id 4466963B494 for ; Mon, 22 Aug 2005 19:50:34 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=furball.foretec.com) by foretec.com with esmtp (Exim 4.30) id 1E7HnY-0007VB-8P; Mon, 22 Aug 2005 15:17:32 -0400 Received: from 10.27.16.5 (SquirrelMail authenticated user ids) by furball.foretec.com with HTTP; Mon, 22 Aug 2005 15:17:32 -0400 (EDT) Message-ID: <2494.10.27.16.5.1124738252.squirrel@furball.foretec.com> In-Reply-To: <4309EDAE.6000303@vandyke.com> References: <4309EDAE.6000303@vandyke.com> Date: Mon, 22 Aug 2005 15:17:32 -0400 (EDT) Subject: Re: Please publish the attached draft-ietf-secsh-publickeyfile-09.txt From: internet-drafts@ietf.org To: "Joseph Galbraith" Cc: ietf-ssh@NetBSD.org Reply-To: internet-drafts@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit The Secretariat CANNOT process your Internet-Draft submission due to following reason(s): * All Internet-Drafts must have on the first page an intellectual property rights (IPR) statement that says: 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. If you are using xml2rfc, this can be accomplished by updating the 'ipr' attribute in the 'rfc' element to refer to 3978. See http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr for more information. > Please publish the attached draft-ietf-secsh-publickeyfile-09.txt > > Thanks, > > Joseph > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 18:50:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7L7K-0005KT-U5 for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 18:50:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28588 for ; Mon, 22 Aug 2005 18:50:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 093DD63B408; Mon, 22 Aug 2005 22:50:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id DFDE963B402 for ; Mon, 22 Aug 2005 22:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7L7B-0000C0-VW; Mon, 22 Aug 2005 18: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-publickeyfile-09.txt Message-Id: Date: Mon, 22 Aug 2005 18:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-09.txt Pages : 14 Date : 2005-8-22 This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-09.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-publickeyfile-09.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-publickeyfile-09.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: <2005-8-22162958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-22162958.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 19:41:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Luh-0006dz-3s for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 19:41:11 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04981 for ; Mon, 22 Aug 2005 19:41:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A7F5B63B248; Mon, 22 Aug 2005 23:41:07 +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 C7FBF63B1D1 for ; Mon, 22 Aug 2005 23:41:06 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7MNf6WR027348 for ; Mon, 22 Aug 2005 17:41:06 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7MNf5WB010066; Mon, 22 Aug 2005 19:41:05 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7MNf57A029342; Mon, 22 Aug 2005 19:41:05 -0400 (EDT) Subject: draft-ietf-secsh-publickeyfile-09.txt resolves outstanding WG Last Call Issues. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1124754064.24824.231.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 22 Aug 2005 19:41:05 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I believe that the recently posted -09 revision of draft-ietf-secsh-publickeyfile resolves the one remaining issue raised during Last Call and that there is WG consensus to publish it as an Informational RFC. I'll be drafting a publication request for Sam in the near future. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 20:13:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MQ8-0005qD-6z for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 20:13:40 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06121 for ; Mon, 22 Aug 2005 20:13:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id ACA0763B262; Tue, 23 Aug 2005 00:13:35 +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 8D82E63B1A0 for ; Tue, 23 Aug 2005 00:13:34 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7N0DL2B024409; Mon, 22 Aug 2005 17:13:21 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7N0DLWB016548; Mon, 22 Aug 2005 20:13:21 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7N0DKXn029433; Mon, 22 Aug 2005 20:13:20 -0400 (EDT) Subject: Please publish draft-ietf-secsh-publickeyfile-09.txt as Informational From: Bill Sommerfeld To: Sam Hartman , Russ Housley Cc: iesg-secretary@ietf.org, ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1124755999.24824.265.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 22 Aug 2005 20:13:20 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit It is the consensus of the Secure Shell working group that draft-ietf-secsh-publickeyfile-09.txt should be published as an Informational RFC. Here's a draft-ietf-proto-wgchair-doc-shepherding-05.txt checklist. 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes; no concerns. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus to publish. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Yes. There is one marginal nit: Strings of the general form " by me@myhost" appear in comments in two of the examples; if the IESG believes that this should be changed to an example.com domain, please issue an RFC editor note to this effect; the exact string used here is not critical to the specification. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes; the one ID reference is to a document in the RFC Editor queue. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 22 23:23:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7POG-0004Xm-7S for secsh-archive@megatron.ietf.org; Mon, 22 Aug 2005 23:23:56 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26564 for ; Mon, 22 Aug 2005 23:23:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8169663B16F; Tue, 23 Aug 2005 03:23:50 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 5971E63B11C for ; Tue, 23 Aug 2005 03:23:49 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA03425; Mon, 22 Aug 2005 23:23:48 -0400 (EDT) From: der Mouse Message-Id: <200508230323.XAA03425@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 22 Aug 2005 23:14:30 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-09.txt In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Filename : draft-ietf-secsh-publickeyfile-09.txt Proofreader-style comments, for what they're worth: Line 296: This field is used to store the login-name that the key was generated s/-/ / Line 313 existing implementations fail if these quotation marks are omitted s/$/./ Line 324: New headers that are of the from "x-" are considered experimental, s/from/form/ Line 588: solely one it's 2nd-preimage resistance, not on it's collision- s/one/on/ s/it's/its/g s/collision-/collision/ /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 00:00:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Pxr-0003I2-Pj for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:00:44 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28026 for ; Tue, 23 Aug 2005 00:00:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 129A763B263; Tue, 23 Aug 2005 04:00:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 45B3363B12F for ; Tue, 23 Aug 2005 04:00:10 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7798255; Mon, 22 Aug 2005 22:00:09 -0600 Message-ID: <430AA122.3070406@vandyke.com> Date: Mon, 22 Aug 2005 22:08:02 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org, Bill Sommerfeld Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1123619096.2981.28.camel@thunk> <200508100603.CAA03178@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200508100603.CAA03178@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sorry, this got lost in the clutter and I didn't get it addressed before I respun the draft. der Mouse wrote: >> It looks like we ratholed on the line termination question. [...] > >> I believe the consensus position is to weaken section 3.1, [to] >> something along the lines of: > >> Implementations SHOULD generate public key files using their >> system's local text file representation. >> >> In the event that public key files are not transferred as text >> files, implementations SHOULD be prepared to read files using any >> of the common line termination sequence, , or . > > As one of the noisier participants in the line termination blather, I'm > prepared to sign off on that wording. (Maybe the second paragraph > should say something more like "To ease interoperability in case public > key files are...", which I think is closer to the intended meaning?) Hmm... that does seem a little better... I'd be happy to change it to this... but Bill just sent a publish request. Bill, should I respin again? Is this something that can be done during the RFC editor process? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 00:00:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Py3-0003K4-8c for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:00:55 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28036 for ; Tue, 23 Aug 2005 00:00:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C9F0163B296; Tue, 23 Aug 2005 04:00:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 3351263B267 for ; Tue, 23 Aug 2005 04:00:47 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7798262 for ietf-ssh@NetBSD.org; Mon, 22 Aug 2005 22:00:46 -0600 Message-ID: <430AA147.40906@vandyke.com> Date: Mon, 22 Aug 2005 22:08:39 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: filexfer: rationale style text in draft... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I've a question for you draft-writing pros... Strewn throughout the filexfer draft are comments like the following examples: > However, to ease the burden of implementation on servers that > use a single, simple, seperator sequence... or > Note that the name "supported2" is used here to avoid conflict > with the slightly different "supported" extension that was > previously used. In addition, there is the 'change-log' section. Am I correct in thinking that this kinds of 'rationale' or 'history' type comments are not appropriate, and should be removed? Is there any official guidance on these kinds of things? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 00:06:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Q3Q-0004v5-8L for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:06:28 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28203 for ; Tue, 23 Aug 2005 00:06:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E848863B267; Tue, 23 Aug 2005 04:06:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 4C1A963B12F for ; Tue, 23 Aug 2005 04:06:24 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7798257 for ietf-ssh@NetBSD.org; Mon, 22 Aug 2005 22:06:23 -0600 Message-ID: <430AA298.5090004@vandyke.com> Date: Mon, 22 Aug 2005 22:14:16 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: filexfer: Proposed revision Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit In Section 3.3, we have the following text: > The use of additional packet types in the non-extension > range MUST be introduced through IETF consensus. New > packet types to be sent from the client to the server > MAY be introduced without changing the protocol > version (Section 4). Because the client has no way > to respond to unrecognized packet types, new packet > types to be sent from the server to the client the > client MUST not used unless the protocol version is > changed or the client has negotiated to received them. > This negotiation MAY be explicit, through the use of > extensions, or MAY be implicit, by the client itself > using a packet type not defined above. Do we really need this much verbosity, or would the following paragraph do: > The use of additional packet types in the non-extension > range MUST be introduced through IETF consensus. New > packet types MAY be introduced without changing the > version where this can be done in a backwards compatible > way. What do people think? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 00:32:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7QSf-0001G0-BU for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:32:33 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28964 for ; Tue, 23 Aug 2005 00:32:30 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 38EF263B11D; Tue, 23 Aug 2005 04:32:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 9E86063B111 for ; Tue, 23 Aug 2005 04:32:28 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7798316 for ietf-ssh@NetBSD.org; Mon, 22 Aug 2005 22:32:27 -0600 Message-ID: <430AA8B5.6070706@vandyke.com> Date: Mon, 22 Aug 2005 22:40:21 -0600 From: Joseph Galbraith User-Agent: Mail/News 1.0+ (Windows/20050727) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: filexfer: Clarifying filename charset-name... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit In section 5. we define the following extension: string filename-charset string charset-name Does anyone know: a. What reference should go with charset-name? b. For this poor implementor, is there a well-defined way to map from LC_CTYPE to a charset-name on a posix (unix) OS? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 08:59:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7YNR-0007Bn-1a for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 08:59:42 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01866 for ; Tue, 23 Aug 2005 08:59:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C614C63B245; Tue, 23 Aug 2005 12:59:28 +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 0BD1663B242 for ; Tue, 23 Aug 2005 12:59:27 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: filexfer: Proposed revision Date: Tue, 23 Aug 2005 09:01:55 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB91883FD@beacon.PSC.process.com> Thread-Topic: filexfer: Proposed revision Thread-Index: AcWnmGf9KYZ0lKoQQ9K/QBa7Mu8pVwASfq1g From: "Richard Whalen" To: "Joseph Galbraith" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable The simplified paragraph works for me. -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On Behalf Of Joseph Galbraith Sent: Tuesday, August 23, 2005 12:14 AM To: ietf-ssh@NetBSD.org Subject: filexfer: Proposed revision In Section 3.3, we have the following text: > The use of additional packet types in the non-extension > range MUST be introduced through IETF consensus. New > packet types to be sent from the client to the server > MAY be introduced without changing the protocol > version (Section 4). Because the client has no way > to respond to unrecognized packet types, new packet > types to be sent from the server to the client the > client MUST not used unless the protocol version is > changed or the client has negotiated to received them. > This negotiation MAY be explicit, through the use of > extensions, or MAY be implicit, by the client itself > using a packet type not defined above. Do we really need this much verbosity, or would the following paragraph do: > The use of additional packet types in the non-extension > range MUST be introduced through IETF consensus. New > packet types MAY be introduced without changing the > version where this can be done in a backwards compatible > way. What do people think? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 11:39:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aro-0007XB-RT for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 11:39:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10498 for ; Tue, 23 Aug 2005 11:39:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 152CC63B183; Tue, 23 Aug 2005 15:39:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (drno.siliconcircus.com [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 5E46863B10D for ; Tue, 23 Aug 2005 15:39:05 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id DECC975622; Tue, 23 Aug 2005 17:38:28 +0200 (CEST) Message-ID: <430B4308.6030409@siliconcircus.com> Date: Tue, 23 Aug 2005 17:38:48 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: WG Last Call on draft-ietf-secsh-publickey-subsystem-02 References: <3EF96AF20489A34296050FBD5C36ECB91883AB@beacon.PSC.process.com> <1123694868.10124.24.camel@thunk> <200508102207.SAA07620@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200508102207.SAA07620@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, der Mouse wrote: > > In 2.1: > The public-key subsystem is opened when the clients sends a > SSH_MSG_CHANNEL_REQUEST over an existing session. > This has so many minor mistakes that rather than try to fix each one > individually, I'll just propose a rewrite: > The public-key subsystem is opened by a client sending a > SSH_MSG_CHANNEL_REQUEST over an existing session's channel. I've changed this to: The public-key subsystem is started by a client sending an SSH_MSG_CHANNEL_REQUEST over an existing session's channel. > Fourteen lines further down in 2.1: > Client implementations SHOULD reject this request; it is normally > only sent by the client. > s/only sent/sent only/ Changed. > Nine lines further down: > authenticated with a restricted public key that does not allow access > to the publickey subsystem. > Proposed rewrite: > authenticated by a means (such as a restricted public key) that does > not allow access to the publickey subsystem. I've written this so (since I figure it's not necessarily just dependent on authentication method): The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the publickey subsystem (for example because the user authenticated with a restricted public key). > In 2.2: > The length field describes the length of the request-name field and > the request-specific data, but not of the length field itself. The > s/but not of/but does not include/ I've done s/but not of/but does not include the length of/. I'm not sure this makes things clearer, but it's difficult to come up with something that's both grammatically and technically clear. > A few lines further down, I see "the...'data' portion of the packet", > but there is no field called "data": > uint32 length > string request-name > ... request specific data follows > My preferred fix here is to s/'data'/the data/. I now have "...of the 'name' field and the data part of the packet.". (It's no longer 'request-name' since it now covers responses too, see below.) > I'd like to see something explicit in 2.3 stating that the length works > the same way it does in 2.2 - perhaps 2.2 and the non-subsectioned > portion of 2.3 could be collapsed, since they otherwise will include a > lot of duplicated, or nearly duplicated, language? I've collapsed the two sections together. > In 2.3.1.1, I see no description of what the intended semantics of the > return codes are, except for the description implicit in their names. > Do we have consensus that this is sufficient? While I think it > probably is for native anglophones, I don't have any other perspective > on it myself - and even if it is sufficient, I'd prefer to see a short > statement to that effect. I've added: 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. Also, I've added this clarification to the description of the version packet: The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent in response to any other request. > Section 3 ("Public-Key Subsystem Operations") starts by saing that > "[t]he public-key subsystem currently defines four operations: add, > remove, list, and listattributes", and then proceeds to section 3.1, > which describes something (version negotiation) that does not appear to > be any of those four and therefore I would argue does not belong in > section 3 as it currently stands. I've moved it to section 2. > In 3.1, in case of an unsupported version, "[b]efore closing the > subsystem, a status message with the status > SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent". But 2.3.1, which > describes status messages, writes of them only as responses to > requests, and the version packet is not described as a request (though > it fits the format of requests). It says "A request is acknowledged by sending a status packet.", without excluding the possibility that the status packet might be used for other things, such as here. > I'm not sure this is worth fixing, though I'd prefer to see a brief > note recognizing this slight mismatch, such as > .... Before closing the subsystem, a status message with the status > SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent, even though the > "version" packet is not a normal request. I've added this note instead: 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. I've also changed the title "The Status Response" to "The Status Message". > In 3.2, I see > algorithm names in [1]. If the server does not implement a mandatory > attribute, it MUST fail the add. > but, in contrast to the error conditions described in the previous > paragraph, I see no indication of what error code should be used. (I > also don't see any error code whose name makes it look suited to this > error condition, and GENERAL_FAILURE is notably unhelpful.) I've added an SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED status code (9) and referenced it here. > In 3.2, describing the "comment-language" attribute, > [5]. The client MAY specify more than comment if it additionally > specifies a different language for each of those comments. The > Based on the context, I believe s/more than /&one / is needed here. Done. > In 3.2, describing the "subsystem" attribute, on first sight, it > appears that there is no way to specify a key that permits any > subsystem. (Presumably the way is to not specify the attribute at all. > But this is not obvious at first sight; indeed, it wasn't until I was > writing the first version of this paragraph that I realized it.) I've added If the "subsystem" attribute is not specified, no restrictions are placed on which subsystems may be started when authenticated using this key. > In 3.3, no indication is given of what to do if the removal succeeds, > or for that matter if it fails. (I assume SUCCESS and KEY_NOT_FOUND > are the principal return codes, with a few others like ACCESS_DENIED > possible, but I'd still rather see it explicit.) I think success is now covered by the text added in the status codes section. We could explicitly cover KEY_NOT_FOUND (maybe with a SHOULD). I wouldn't want to get into discussing when ACCESS_DENIED should be sent, I think. > In 3.4, no explicit provision is made for servers that support the > request but choose to deny it for the client in question. I'd prefer > to see this changed. I could add (indeed, did add, but took it out again): An implementation MAY also choose to respond with SSH_PUBLICKEY_ACCESS_DENIED if it does not wish to provide the list for a given client. I'm dubious - implementations may choose to do that for any of the other requests. Unless I've missed something, there's nothing stopping them, which would imply adding similar text for each request, which seems like overkill. > In 3.2 and 3.5, no provision is made for a server that supports a > specific attribute but is administratively set to impose a lack of that > attribute - only for imposing the presence of an attribute. The attributes are all negative, they disallow or restrict things. I can't see when the server administrator would want to insist on someone absolutely, positively having to have (say) X11 forwarding allowed for every key they define. > There also > is no provision for cases such as imposing certain hosts' presence or > absence in (say) the "agent" list. I presume you mean the "from" list? For presence, I again don't see the case where an admin wants this. For absence, I've added the following text to the "from" description: The server MAY provide a method for administrators to disallow the appearance of a host in this list. > In 5.2.1, there is a restriction in that the length limit applies even > to domain-localized names. This seems semi-broken, since FQDNs can be > relatively long (though 64 seems generous now, I have little confidence > it will remain so - I already have a private name 43 characters long). You also have one 22 characters long, though (rodents.montreal.qc.ca). > Unless the "names" in "[n]ames are case-sensitive, and MUST NOT be > longer than 64 characters" refers to just the part before the @, in > which case I think the language needs clarification - this section uses > "name" to refer to both the whole string and just the part before the > @, which is confusing; consider "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.", which uses the word in > both senses in the same sentence. This text (and the length) is directly taken from the core numbers draft. I figure the potential of people not being able to come up with 64-character names is not worth the inconsistency with that - though I'll happily change the publickey subsystem's text if the text in the numbers draft changes... I'm just about to respin the draft based on these changes (and because the current version is due to expire in September). -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 11:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7b3T-0003LL-1t for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 11:51:16 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11687 for ; Tue, 23 Aug 2005 11:51:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A78663B183; Tue, 23 Aug 2005 15:51:10 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 2E92963B10D for ; Tue, 23 Aug 2005 15:51:06 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 12209735CD; Tue, 23 Aug 2005 17:49:50 +0200 (CEST) Message-ID: <430B45B0.30605@siliconcircus.com> Date: Tue, 23 Aug 2005 17:50:08 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-03.txt Content-Type: multipart/mixed; boundary="------------020901030403050201060002" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------020901030403050201060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached draft-ietf-secsh-publickey-subsystem-03.txt -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------020901030403050201060002 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-03.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-03.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: February 24, 2006 B. McClure VanDyke Software J. Bright Silicon Circus August 23, 2005 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 February 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. Galbraith, et al. Expires February 24, 2006 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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. Galbraith, et al. Expires February 24, 2006 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 5 2.1 Opening the Public-Key Subsystem . . . . . . . . . . . . . 5 2.2 Requests and Responses . . . . . . . . . . . . . . . . . . 6 2.3 The Status Message . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Status Codes . . . . . . . . . . . . . . . . . . . . . 6 2.4 The Version Packet . . . . . . . . . . . . . . . . . . . . 7 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 8 3.1 Adding a public key . . . . . . . . . . . . . . . . . . . 8 3.2 Removing a public key . . . . . . . . . . . . . . . . . . 11 3.3 Listing public keys . . . . . . . . . . . . . . . . . . . 11 3.4 Listing server capabilities . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1 Conventions for Names . . . . . . . . . . . . . . . . 14 5.2.2 Future Assignments of Names . . . . . . . . . . . . . 14 5.3 Request names . . . . . . . . . . . . . . . . . . . . . . 15 5.4 Response names . . . . . . . . . . . . . . . . . . . . . . 15 5.5 Attribute names . . . . . . . . . . . . . . . . . . . . . 15 5.6 Status codes . . . . . . . . . . . . . . . . . . . . . . . 16 5.6.1 Conventions . . . . . . . . . . . . . . . . . . . . . 16 5.6.2 Initial Assignments . . . . . . . . . . . . . . . . . 16 5.6.3 Future Assignments . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1 Normative References . . . . . . . . . . . . . . . . . . . 17 6.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Galbraith, et al. Expires February 24, 2006 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem August 2005 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires February 24, 2006 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem August 2005 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1 Opening the Public-Key Subsystem The public-key subsystem is 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 publickey 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 February 24, 2006 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem August 2005 2.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 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 3 are a description of the 'name' field and the data part of the packet. 2.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-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. 2.3.1 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 February 24, 2006 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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. 2.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 The version of the protocol described by this document is version 2. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. 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 February 24, 2006 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem August 2005 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and listattributes. 3.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 mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. Galbraith, et al. Expires February 24, 2006 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem August 2005 The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorisation checks the server may perform). This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. 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 mandatory. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" Galbraith, et al. Expires February 24, 2006 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem August 2005 "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. Galbraith, et al. Expires February 24, 2006 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem August 2005 3.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. 3.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. 3.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 February 24, 2006 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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 February 24, 2006 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem August 2005 4. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorise keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires February 24, 2006 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem August 2005 5. IANA Considerations This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments. 5.1 Registrations Consistent with section 7 of [1], this document makes the following registration: The subsystem name "publickey". 5.2 Names In the following sections, the values for the name spaces 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. 5.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 [8] 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 [7] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [7]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). 5.2.2 Future Assignments of Names Requests for assignments of new Names MUST be done through the IETF Galbraith, et al. Expires February 24, 2006 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem August 2005 CONSENSUS method as described in [9]. 5.3 Request names The following table lists the initial assignments of Request names Request Name ------------- version add remove list listattributes 5.4 Response names The following table lists the initial assignments of Response names Response Name -------------- version status publickey attribute 5.5 Attribute names Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Response names Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward Galbraith, et al. Expires February 24, 2006 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem August 2005 5.6 Status codes The status code is a byte value, describing the status of a request. 5.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. 5.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 5.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 [9]. 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 February 24, 2006 [Page 16] Internet-Draft Secure Shell Public-Key Subsystem August 2005 6. References 6.1 Normative References [1] Lonvick, C., "SSH Protocol Architecture", Internet-Draft draft-ietf-secsh-architecture-22, March 2005. [2] Lonvick, C., "SSH Transport Layer Protocol", Internet-Draft draft-ietf-secsh-transport-24, March 2005. [3] Lonvick, C., "SSH Authentication Protocol", Internet-Draft draft-ietf-secsh-userauth-27, March 2005. [4] Lonvick, C., "SSH Connection Protocol", Internet-Draft draft-ietf-secsh-connect-25, March 2005. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 6.2 Informative References [7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Galbraith, et al. Expires February 24, 2006 [Page 17] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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 February 24, 2006 [Page 18] Internet-Draft Secure Shell Public-Key Subsystem August 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith, et al. Expires February 24, 2006 [Page 19] --------------020901030403050201060002-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 13:41:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7clx-0005hD-5D for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 13:41:17 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17963 for ; Tue, 23 Aug 2005 13:41:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 172C463B4F0; Tue, 23 Aug 2005 17:40:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from foretec.com (furball.foretec.com [132.151.15.110]) by mail.netbsd.org (Postfix) with ESMTP id 381E663B183 for ; Tue, 23 Aug 2005 17:40:34 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=furball.foretec.com) by foretec.com with esmtp (Exim 4.30) id 1E7clE-0002z3-ML; Tue, 23 Aug 2005 13:40:32 -0400 Received: from 10.27.16.5 (SquirrelMail authenticated user ids) by furball.foretec.com with HTTP; Tue, 23 Aug 2005 13:40:32 -0400 (EDT) Message-ID: <4145.10.27.16.5.1124818832.squirrel@furball.foretec.com> In-Reply-To: <430B45B0.30605@siliconcircus.com> References: <430B45B0.30605@siliconcircus.com> Date: Tue, 23 Aug 2005 13:40:32 -0400 (EDT) Subject: Re: Submission: draft-ietf-secsh-publickey-subsystem-03.txt From: internet-drafts@ietf.org To: "Jon Bright" Cc: ietf-ssh@NetBSD.org Reply-To: internet-drafts@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit The Secretariat CANNOT process your Internet-Draft submission due to following reason(s): * All Internet-Drafts must have on the first page an intellectual property rights (IPR) statement that says: 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. If you are using xml2rfc, this can be accomplished by updating the 'ipr' attribute in the 'rfc' element to refer to 3978. See http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr for more information. > Hi, > > Please publish the attached draft-ietf-secsh-publickey-subsystem-03.txt > > -- > Jon Bright > Silicon Circus Ltd. > http://www.siliconcircus.com > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 14:14:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dHh-0006eQ-E2 for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 14:14:07 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20004 for ; Tue, 23 Aug 2005 14:14:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 21BDD63B692; Tue, 23 Aug 2005 18:14:01 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 5D13C63B689 for ; Tue, 23 Aug 2005 18:14:00 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa19867; 23 Aug 2005 14:13 EDT Date: Tue, 23 Aug 2005 14:13:25 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: filexfer: rationale style text in draft... Message-ID: In-Reply-To: <430AA147.40906@vandyke.com> References: <430AA147.40906@vandyke.com> Originator-Info: login-token=Mulberry:014Zx/HEsE9JAt5/edFBqvi3gOtkdo0PhOEa2BFxw=; 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 Content-Transfer-Encoding: 7bit On Monday, August 22, 2005 10:08:39 PM -0600 Joseph Galbraith wrote: > I've a question for you draft-writing pros... > > Strewn throughout the filexfer draft are comments like the > following examples: > > > However, to ease the burden of implementation on servers that > > use a single, simple, seperator sequence... > > or > > > Note that the name "supported2" is used here to avoid conflict > > with the slightly different "supported" extension that was > > previously used. > > In addition, there is the 'change-log' section. > > Am I correct in thinking that this kinds of 'rationale' > or 'history' type comments are not appropriate, and > should be removed? The changelog should generally be removed in the RFC-editor process. Rationale does not in general seem inappropriate to me, especially when the reason for a decision is non-obvious. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 14:18:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dM5-0007aP-39 for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 14:18:37 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20477 for ; Tue, 23 Aug 2005 14:18:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 660A163B689; Tue, 23 Aug 2005 18:18:33 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id A660463B123 for ; Tue, 23 Aug 2005 18:18:32 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa19870; 23 Aug 2005 14:17 EDT Date: Tue, 23 Aug 2005 14:17:48 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: filexfer: Clarifying filename charset-name... Message-ID: In-Reply-To: <430AA8B5.6070706@vandyke.com> References: <430AA8B5.6070706@vandyke.com> Originator-Info: login-token=Mulberry:01T9hb+rlA0G6bI9N7glaLaeZKkiXWDNS8TYlfhVg=; 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 Content-Transfer-Encoding: 7bit On Monday, August 22, 2005 10:40:21 PM -0600 Joseph Galbraith wrote: > In section 5. we define the following extension: > > string filename-charset > string charset-name > > Does anyone know: > > a. What reference should go with charset-name? BCP19, and the IANA charset registry. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 15:50:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7emq-0003gP-H2 for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 15:50:20 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26890 for ; Tue, 23 Aug 2005 15:50:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A34C063B6CD; Tue, 23 Aug 2005 19:50:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 6DF9863B6C6 for ; Tue, 23 Aug 2005 19:50:05 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7emX-00033a-Qw; Tue, 23 Aug 2005 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-gsskeyex-10.txt Message-Id: Date: Tue, 23 Aug 2005 15:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol Author(s) : J. Hutzelman, et al. Filename : draft-ietf-secsh-gsskeyex-10.txt Pages : 34 Date : 2005-8-23 The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method which uses a specified GSSAPI mechanism to authenticate a user, and a family of SSH key exchange methods which use GSSAPI to authenticate a Diffie-Hellman key exchange. This memo also defines a new host public key algorithm which can be used when no operations are needed using a host's public key, and a new user authentication method which allows an authorization name to be used in conjunction with any authentication which has already occurred as a side-effect of GSSAPI-based key exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-10.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-gsskeyex-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-10.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: <2005-8-23135353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-23135353.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 23 18:06:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7guB-0002Ld-Kt for secsh-archive@megatron.ietf.org; Tue, 23 Aug 2005 18:06:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14805 for ; Tue, 23 Aug 2005 18:06:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A82AF63B19A; Tue, 23 Aug 2005 22:05:55 +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 1574E63B117 for ; Tue, 23 Aug 2005 22:05:55 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7NM5s2B009730; Tue, 23 Aug 2005 15:05:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7NM5rUj018260; Tue, 23 Aug 2005 18:05:53 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7NM5rtB004186; Tue, 23 Aug 2005 18:05:53 -0400 (EDT) Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: der Mouse , ietf-ssh@NetBSD.org In-Reply-To: <430AA122.3070406@vandyke.com> References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1123619096.2981.28.camel@thunk> <200508100603.CAA03178@Sparkle.Rodents.Montreal.QC.CA> <430AA122.3070406@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1124834752.2184.60.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Tue, 23 Aug 2005 18:05:53 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-08-23 at 00:08, Joseph Galbraith wrote: > Hmm... that does seem a little better... I'd be happy to change > it to this... but Bill just sent a publish request. Whoops. > Bill, should I respin again? It's up to you but if it's easy you might as well update it now. > Is this something that can be done during the RFC editor process? You can do it that way, too, but I think it would be easier to get it now. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 24 02:13:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7oWK-0000Ct-SK for secsh-archive@megatron.ietf.org; Wed, 24 Aug 2005 02:13:57 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16214 for ; Wed, 24 Aug 2005 02:13:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CCE6763B175; Wed, 24 Aug 2005 06:13:13 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 63A3063B24F for ; Wed, 24 Aug 2005 06:13:09 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 3617873008; Wed, 24 Aug 2005 08:11:53 +0200 (CEST) Message-ID: <430C0FA8.8080007@siliconcircus.com> Date: Wed, 24 Aug 2005 08:11:52 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-03.txt Content-Type: multipart/mixed; boundary="------------090602070604070904050707" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------090602070604070904050707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached draft-ietf-secsh-publickey-subsystem-03.txt (now with IPR corrections). -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------090602070604070904050707 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-03.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-03.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: February 25, 2006 B. McClure VanDyke Software J. Bright Silicon Circus August 24, 2005 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-03.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 February 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client Galbraith, et al. Expires February 25, 2006 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 4 2.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 4 2.2. Requests and Responses . . . . . . . . . . . . . . . . . . 5 2.3. The Status Message . . . . . . . . . . . . . . . . . . . . 5 2.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 5 2.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 6 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 7 3.1. Adding a public key . . . . . . . . . . . . . . . . . . . 7 3.2. Removing a public key . . . . . . . . . . . . . . . . . . 10 3.3. Listing public keys . . . . . . . . . . . . . . . . . . . 10 3.4. Listing server capabilities . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Conventions for Names . . . . . . . . . . . . . . . . 13 5.2.2. Future Assignments of Names . . . . . . . . . . . . . 13 5.3. Request names . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Response names . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Attribute names . . . . . . . . . . . . . . . . . . . . . 14 5.6. Status codes . . . . . . . . . . . . . . . . . . . . . . . 15 5.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 15 5.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 15 5.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Galbraith, et al. Expires February 25, 2006 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem August 2005 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires February 25, 2006 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem August 2005 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1. Opening the Public-Key Subsystem The public-key subsystem is 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 publickey 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 February 25, 2006 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem August 2005 2.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 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 3 are a description of the 'name' field and the data part of the packet. 2.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-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. 2.3.1. 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 February 25, 2006 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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. 2.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 The version of the protocol described by this document is version 2. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. 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 February 25, 2006 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem August 2005 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and listattributes. 3.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 mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. Galbraith, et al. Expires February 25, 2006 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem August 2005 The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorisation checks the server may perform). This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. 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 mandatory. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" Galbraith, et al. Expires February 25, 2006 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem August 2005 "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. Galbraith, et al. Expires February 25, 2006 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem August 2005 3.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. 3.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. 3.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 February 25, 2006 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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 February 25, 2006 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem August 2005 4. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorise keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires February 25, 2006 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem August 2005 5. IANA Considerations This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments. 5.1. Registrations Consistent with section 7 of [1], this document makes the following registration: The subsystem name "publickey". 5.2. Names In the following sections, the values for the name spaces 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. 5.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 [8] 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 [7] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [7]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). 5.2.2. Future Assignments of Names Requests for assignments of new Names MUST be done through the IETF Galbraith, et al. Expires February 25, 2006 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem August 2005 CONSENSUS method as described in [9]. 5.3. Request names The following table lists the initial assignments of Request names Request Name ------------- version add remove list listattributes 5.4. Response names The following table lists the initial assignments of Response names Response Name -------------- version status publickey attribute 5.5. Attribute names Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Response names Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward Galbraith, et al. Expires February 25, 2006 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem August 2005 5.6. Status codes The status code is a byte value, describing the status of a request. 5.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. 5.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 5.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 [9]. 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 February 25, 2006 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem August 2005 6. References 6.1. Normative References [1] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. [2] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [3] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-27 (work in progress), March 2005. [4] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 6.2. Informative References [7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Galbraith, et al. Expires February 25, 2006 [Page 16] Internet-Draft Secure Shell Public-Key Subsystem August 2005 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 February 25, 2006 [Page 17] Internet-Draft Secure Shell Public-Key Subsystem August 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith, et al. Expires February 25, 2006 [Page 18] --------------090602070604070904050707-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 24 17:22:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82hD-0005u3-2R for secsh-archive@megatron.ietf.org; Wed, 24 Aug 2005 17:22:09 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22244 for ; Wed, 24 Aug 2005 17:21:28 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 814C063B12C; Wed, 24 Aug 2005 21:20:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id 973D763B123 for ; Wed, 24 Aug 2005 21:20:58 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BF547E0049; Wed, 24 Aug 2005 17:19:52 -0400 (EDT) To: Bill Sommerfeld Cc: Jeffrey Hutzelman , David Leonard , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> From: Sam Hartman Date: Wed, 24 Aug 2005 17:19:52 -0400 In-Reply-To: <1124733504.24824.191.camel@thunk> (Bill Sommerfeld's message of "Mon, 22 Aug 2005 13:58:25 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Bill" == Bill Sommerfeld writes: Bill> On Fri, 2005-08-19 at 00:32, Jeffrey Hutzelman wrote: >> I have been asked to submit an updated version of this document >> within the next few days, in order to get it on the agenda for >> the September 1 IESG telechat. Unless Bill finds that we have >> consensus for a change in this area, I will submit the draft >> early next week with no further changes. Bill> Bill> I've reviewed the messages exchanged so far on this issue. Bill> I see what looks like consensus that there's a hole in the Bill> spec: the spec as it stands is silent on what an Bill> implementation should do if a hostname is not available. Bill> I agree that the spec is silent on what an implementation should do if the hostname is not available. It is not a requirement that the specification define semantics for all cases only that sufficient semantics be defined that all implementations are interoperable. It seems that is true for this specification in the case where a hostname is available. The fact that there are security concerns if the wrong thing is done may make fixing this hole in the spec a requirement. Never the less if we can come to quick consensus on a fix then we should include it. Bill> IMHO, the main thing that matters for interoperability is Bill> the complete client system behavior rather than the behavior Bill> of the part of the system which is above the GSS *API* Bill> boundary. Bill> Given that this question is being looked at within GSSAPI, Bill> perhaps the best we can say for now is that if a client Bill> system implementing this specification is unable to securely Bill> determine which hostname and/or GSS target name to use, then Bill> it SHOULD NOT use this mechanism. Jeff, would you please draft text to be added in an rfc editor note to do this? I'm seeking comments on the following three issues: * Is Bill's solution a good idea * Is it a requirement that we fix this hole * Is Jeff's text good? My presumption (what I'll do absent comments) is as follows. Bill's solution is good and Jeff's text is good provided I don't find major problems with it. My presumption is also that fixing this issue is optional. My personal opinions do align with my presumptions. I am still a bit concerned that because of the security problems we may actually need to fix this spec deficiency and so I'd much rather have agreement on a fix than have to think about whether to block publication. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 24 18:50:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E844O-0003eE-AZ for secsh-archive@megatron.ietf.org; Wed, 24 Aug 2005 18:50:08 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27699 for ; Wed, 24 Aug 2005 18:50:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1163363B415; Wed, 24 Aug 2005 22:50:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 0F96F63B2E2 for ; Wed, 24 Aug 2005 22:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E844H-0004LF-Hg; Wed, 24 Aug 2005 18: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-03.txt Message-Id: Date: Wed, 24 Aug 2005 18:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-publickey-subsystem-03.txt Pages : 19 Date : 2005-8-24 SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in 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-03.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-03.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-03.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: <2005-8-24161816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-24161816.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 24 19:57:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E857J-00009t-T9 for secsh-archive@megatron.ietf.org; Wed, 24 Aug 2005 19:57:14 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04232 for ; Wed, 24 Aug 2005 19:57:12 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D45D63B34B; Wed, 24 Aug 2005 23:57:09 +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 B48B863B322 for ; Wed, 24 Aug 2005 23:57:08 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7ONv42B024760; Wed, 24 Aug 2005 16:57:08 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7ONv3WB004907; Wed, 24 Aug 2005 19:57:03 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7ONv3Gr011230; Wed, 24 Aug 2005 19:57:03 -0400 (EDT) Subject: publickey-subsystem-03: extending last call by a week. From: Bill Sommerfeld To: der Mouse , Jon Bright Cc: ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1124927822.7308.361.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 24 Aug 2005 19:57:03 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-08-24 at 18:50, Internet-Drafts@ietf.org wrote: > Title : Secure Shell Public-Key Subsystem > Author(s) : J. Galbraith, et al. > Filename : draft-ietf-secsh-publickey-subsystem-03.txt > Pages : 19 > Date : 2005-8-24 der Mouse: is this revision acceptable to you? everyone else: are you ok with this version? I'm going to extend the WG Last call timer by a week to August 31st since there's an actual wire protocol changes (a new status code) in this revision. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 24 20:00:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85AL-0001ED-Sl for secsh-archive@megatron.ietf.org; Wed, 24 Aug 2005 20:00:22 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04414 for ; Wed, 24 Aug 2005 20:00:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 267F663B349; Thu, 25 Aug 2005 00:00:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 7CAC463B36F for ; Thu, 25 Aug 2005 00:00:16 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7804851; Wed, 24 Aug 2005 18:00:15 -0600 Message-ID: <430D0BED.50800@vandyke.com> Date: Wed, 24 Aug 2005 18:08:13 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Bill Sommerfeld CC: der Mouse , Jon Bright , ietf-ssh@NetBSD.org Subject: Re: publickey-subsystem-03: extending last call by a week. References: <1124927822.7308.361.camel@thunk> In-Reply-To: <1124927822.7308.361.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > On Wed, 2005-08-24 at 18:50, Internet-Drafts@ietf.org wrote: >> Title : Secure Shell Public-Key Subsystem >> Author(s) : J. Galbraith, et al. >> Filename : draft-ietf-secsh-publickey-subsystem-03.txt >> Pages : 19 >> Date : 2005-8-24 > > der Mouse: is this revision acceptable to you? > > everyone else: are you ok with this version? > > I'm going to extend the WG Last call timer by a week to August 31st > since there's an actual wire protocol changes (a new status code) in > this revision. Do we need to bump the protocol version? I'm pretty sure we are already shipping something that say s it conforms to version 2 that will squawk at the new protocol number. I think there may be others. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 02:10:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8AwK-0003qw-5V for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 02:10:18 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27290 for ; Thu, 25 Aug 2005 02:10:14 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 46F8563B361; Thu, 25 Aug 2005 06:10:03 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 8013563B30A for ; Thu, 25 Aug 2005 06:10:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 771B972FE2; Thu, 25 Aug 2005 08:08:46 +0200 (CEST) Message-ID: <430D6065.80306@siliconcircus.com> Date: Thu, 25 Aug 2005 08:08:37 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith CC: Bill Sommerfeld , der Mouse , ietf-ssh@NetBSD.org Subject: Re: publickey-subsystem-03: extending last call by a week. References: <1124927822.7308.361.camel@thunk> <430D0BED.50800@vandyke.com> In-Reply-To: <430D0BED.50800@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > > Do we need to bump the protocol version? I'm pretty sure > we are already shipping something that say s it conforms > to version 2 that will squawk at the new protocol number. > > I think there may be others. On the one side, it's pretty easy to bump the revision. On the other side, Internet-Drafts blah blah...reference material blah blah...work in progress. My guess would be, most implementations would see the new status code and spit it at the user as being unknown, possibly ending the (publickey) connection. Also, this is only an issue if the status code gets sent at all - if you're only sending attributes returned by listattributes, it shouldn't... If this does turn out to be a problem, the new status code could die and we define GENERAL_FAILURE as the code to send then - but that seems like a poor compromise. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 08:31:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Gsw-0008Az-LC for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 08:31:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15322 for ; Thu, 25 Aug 2005 08:31:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 38D6A63B1F1; Thu, 25 Aug 2005 12:31:06 +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 7054963B103 for ; Thu, 25 Aug 2005 12:31:05 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: publickey-subsystem-03: extending last call by a week. Date: Thu, 25 Aug 2005 08:33:32 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188407@beacon.PSC.process.com> Thread-Topic: publickey-subsystem-03: extending last call by a week. Thread-Index: AcWpB+bJ5ZE8Cw7oRJKmrCAFDsEXlgAaIzyg From: "Richard Whalen" To: "Bill Sommerfeld" , "der Mouse" , "Jon Bright" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable The changes are ok with me. Though we have an implementation that says it conforms to version 2, it currently only checks for success status, so I expect that the new status code will be harmless. ------------------- Richard Whalen Process Software > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On > Behalf Of Bill Sommerfeld > Sent: Wednesday, August 24, 2005 7:57 PM > To: der Mouse; Jon Bright > Cc: ietf-ssh@NetBSD.org > Subject: publickey-subsystem-03: extending last call by a week. >=20 >=20 > On Wed, 2005-08-24 at 18:50, Internet-Drafts@ietf.org wrote: > > Title : Secure Shell Public-Key Subsystem > > Author(s) : J. Galbraith, et al. > > Filename : draft-ietf-secsh-publickey-subsystem-03.txt > > Pages : 19 > > Date : 2005-8-24 >=20 > der Mouse: is this revision acceptable to you? >=20 > everyone else: are you ok with this version? >=20 > I'm going to extend the WG Last call timer by a week to August 31st > since there's an actual wire protocol changes (a new status code) in > this revision. >=20 > - Bill >=20 >=20 >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 09:13:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HXe-0003tx-M6 for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 09:13:15 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16702 for ; Thu, 25 Aug 2005 09:13:12 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 50B9863B4B4; Thu, 25 Aug 2005 13:13:11 +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 B2F5663B4CF for ; Thu, 25 Aug 2005 13:13:10 +0000 (UTC) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7PDD9HT024302; Thu, 25 Aug 2005 06:13:09 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7PDD8f8011958; Thu, 25 Aug 2005 06:13:08 -0700 (PDT) Subject: Re: publickey-subsystem-03: extending last call by a week. From: Bill Sommerfeld To: Joseph Galbraith Cc: der Mouse , Jon Bright , ietf-ssh@NetBSD.org In-Reply-To: <430D0BED.50800@vandyke.com> References: <1124927822.7308.361.camel@thunk> <430D0BED.50800@vandyke.com> Content-Type: text/plain Message-Id: <1124975570.9773.35.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Thu, 25 Aug 2005 14:12:51 +0100 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-08-25 at 01:08, Joseph Galbraith wrote: > Do we need to bump the protocol version? I'm pretty sure > we are already shipping something that says it conforms > to version 2 that will squawk at the new protocol number. I think you have to tell us -- you're probably in the best position to tell us about the relative consequences for your users of: 1) your currently shipping implementation encountering an unknown error code. 2) your currently shipping implementation encountering another implementation which only supports the hypothetical version 3, because the drafts documenting v2 and v1 have long expired. But, in the absence of what I'd think of as a really horrible implementation bug I'm having difficulty understanding why #1 would be worse in practice than #2... - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 19:30:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RAx-00026Y-CW for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 19:30:29 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27705 for ; Thu, 25 Aug 2005 19:30:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DF5D863B259; Thu, 25 Aug 2005 23:30:20 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 96FC363B4E6 for ; Thu, 25 Aug 2005 23:30:19 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa23996; 25 Aug 2005 19:28 EDT Date: Thu, 25 Aug 2005 19:28:34 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Bill Sommerfeld cc: David Leonard , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments Message-ID: In-Reply-To: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> Originator-Info: login-token=Mulberry:01Gqhb84QQ0Gdm89N0TSaLYrEakh6h3NSHHYlYUCg=; 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 Content-Transfer-Encoding: 7bit On Wednesday, August 24, 2005 05:19:52 PM -0400 Sam Hartman wrote: > Bill> IMHO, the main thing that matters for interoperability is > Bill> the complete client system behavior rather than the behavior > Bill> of the part of the system which is above the GSS *API* > Bill> boundary. > > Bill> Given that this question is being looked at within GSSAPI, > Bill> perhaps the best we can say for now is that if a client > Bill> system implementing this specification is unable to securely > Bill> determine which hostname and/or GSS target name to use, then > Bill> it SHOULD NOT use this mechanism. > > > Jeff, would you please draft text to be added in an rfc editor note to > do this? Sure. I think we need a bit of background in addition to the simple requirement Bill mentioned. I'll propose adding the following text to the end of section 7.1 to address this issue: Because the GSSAPI mechanism uses the targ_name to authenticate the server's identity, it is important that it be determined in a secure fashion. One common way to do this is to construct the targ_name from the hostname as typed by the user; unfortunately, because some GSSAPI mechanisms do not canonicalize hostnames, it is likely that this technique will fail if the user has not typed a fully-qualified, canonical hostname. Thus, implementors may wish to use other methods, but should take care to insure they are secure. For example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, or an IP address to a hostname, since an attacker can modify the mapping and impersonate the server. Implementations of mechanisms conforming to this document MUST NOT use the results of insecure DNS queries to construct the targ_name. Clients MAY make use of a mapping provided by local configuration, append a statically configured domain name to unqualified hostnames, and/or use other secure means to determine the targ_name to be used. If a client system is unable to securely determine which targ_name to use, then it SHOULD NOT use this mechanism. > * Is Bill's solution a good idea I think Bill's solution is good, as far as it goes. The basic requirement is that clients that cannot figure out what to do securely SHOULD NOT use this mechanism. The text I proposed provides a little background on why, and also adds the requirement that implementations MUST NOT use insecure DNS to decide what hostname to use. Based on what I've seen in ssh implementations, I don't expect that to be a difficult sell in this WG. > * Is it a requirement that we fix this hole I'm not sure that it is. RFC4120 provides very similar advice to what I provided above, and it is my hope that the next GSSAPI revision will do the same. On the other hand, there is the danger that if we don't call this out, some implementor will think it is a good idea to reverse-resolve an address provided by a user, which would be unfortunate. I think I'll mostly stay neutral on this question. > * Is Jeff's text good? Yes, I think my text is good. :-) -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 19:45:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RPM-0007GC-Dx for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 19:45:22 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28284 for ; Thu, 25 Aug 2005 19:45:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 133C863B399; Thu, 25 Aug 2005 23:45:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 2694B63B285 for ; Thu, 25 Aug 2005 23:45:16 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2005 16:45:15 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7PNjCQM011154; Thu, 25 Aug 2005 16:45:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments Date: Thu, 25 Aug 2005 16:50:05 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C8BEB1@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments Thread-Index: AcWpzaKgPzSii6Z0QImWeUvakkPOtwAAGpoA From: "Salowey, Joe" To: "Jeffrey Hutzelman" , "Sam Hartman" , "Bill Sommerfeld" Cc: "David Leonard" , , , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Thursday, August 25, 2005 4:29 PM > To: Sam Hartman; Bill Sommerfeld > Cc: David Leonard; ietf-ssh@NetBSD.org; Salowey, Joe;=20 > galb@vandyke.com; welch@mcs.anl.gov > Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments >=20 >=20 >=20 > On Wednesday, August 24, 2005 05:19:52 PM -0400 Sam Hartman=20 > wrote: >=20 > > Bill> IMHO, the main thing that matters for interoperability is > > Bill> the complete client system behavior rather than=20 > the behavior > > Bill> of the part of the system which is above the GSS *API* > > Bill> boundary. > > > > Bill> Given that this question is being looked at within GSSAPI, > > Bill> perhaps the best we can say for now is that if a client > > Bill> system implementing this specification is unable=20 > to securely > > Bill> determine which hostname and/or GSS target name=20 > to use, then > > Bill> it SHOULD NOT use this mechanism. > > > > > > Jeff, would you please draft text to be added in an rfc=20 > editor note to=20 > > do this? >=20 > Sure. I think we need a bit of background in addition to the=20 > simple requirement Bill mentioned. I'll propose adding the=20 > following text to the end of section 7.1 to address this issue: >=20 >=20 > Because the GSSAPI mechanism uses the targ_name to authenticate the > server's identity, it is important that it be determined in a secure > fashion. One common way to do this is to construct the targ_name > from the hostname as typed by the user; unfortunately, because some > GSSAPI mechanisms do not canonicalize hostnames, it is likely that > this technique will fail if the user has not typed a=20 > fully-qualified, > canonical hostname. Thus, implementors may wish to use=20 > other methods, > but should take care to insure they are secure. For example, one > should not rely on an unprotected DNS record to map a host alias to > the primary name of a server, or an IP address to a hostname, since > an attacker can modify the mapping and impersonate the server. >=20 > Implementations of mechanisms conforming to this document=20 > MUST NOT use > the results of insecure DNS queries to construct the=20 > targ_name. Clients > MAY make use of a mapping provided by local configuration, append a > statically configured domain name to unqualified hostnames,=20 > and/or use > other secure means to determine the targ_name to be used. =20 > If a client > system is unable to securely determine which targ_name to=20 > use, then it > SHOULD NOT use this mechanism. > [Joe] I think this text is good. =20 >=20 >=20 > > * Is Bill's solution a good idea >=20 > I think Bill's solution is good, as far as it goes. The=20 > basic requirement is that clients that cannot figure out what=20 > to do securely SHOULD NOT use this mechanism. The text I=20 > proposed provides a little background on why, and also adds=20 > the requirement that implementations MUST NOT use insecure=20 > DNS to decide what hostname to use. Based on what I've seen=20 > in ssh implementations, I don't expect that to be a difficult=20 > sell in this WG. >=20 >=20 >=20 > > * Is it a requirement that we fix this hole >=20 > I'm not sure that it is. RFC4120 provides very similar=20 > advice to what I provided above, and it is my hope that the=20 > next GSSAPI revision will do the same. On the other hand,=20 > there is the danger that if we don't call this out, some=20 > implementor will think it is a good idea to reverse-resolve=20 > an address provided by a user, which would be unfortunate. >=20 > I think I'll mostly stay neutral on this question. >=20 [Joe] It is important that we describe the issue. We can't completely fix the hole in this spec, we can at least put up warning signs and recommend that they don't go there.=20 >=20 >=20 > > * Is Jeff's text good? >=20 > Yes, I think my text is good. :-) >=20 >=20 > -- Jeff >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 21:33:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8T63-0006rn-Mp for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 21:33:32 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06542 for ; Thu, 25 Aug 2005 21:33:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 705E763B187; Fri, 26 Aug 2005 01:33:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from fsau.vintela.com (unknown [202.183.100.57]) by mail.netbsd.org (Postfix) with ESMTP id 1977F63B110 for ; Fri, 26 Aug 2005 01:33:24 +0000 (UTC) Received: from lark.vintela.com (lark.vintela.com [10.20.36.133]) by fsau.vintela.com (Postfix) with ESMTP id 7ABBD32E3D; Fri, 26 Aug 2005 11:33:20 +1000 (EST) Date: Fri, 26 Aug 2005 11:33:17 +1000 (EST) From: David Leonard X-X-Sender: davidl@lark.vintela.com To: Jeffrey Hutzelman Cc: Sam Hartman , Bill Sommerfeld , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments In-Reply-To: Message-ID: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> Organization: Vintela; Quest Software MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list I have to strongly disagree with this approach. My view is that the application should not canonicalize the hostname (as supplied by the user) before passing it to GSS in a targ_name. This is because the GSS mechanisms may be sensitive to non-canonicalized names, and indeed the GSS mechanisms may do their own secure canonicalization themselves. I propose instead for 7.1 that a client system SHOULD first construct targ_name = "host@"+hostname (without modifying the user-supplied hostname) and try GSS. Then, if the GSS fails [?], the application SHOULD try canonicalizing the hostname and construct targ_name2 = "host@"+canonicalize(hostname) and try that instead (if it's a different string). This serves the need for interoperability with GSS mechanisms that do not canonicalize, and the (more important) need for passing user-supplied hostname strings as-is to the GSS mechanisms. I note that when constructing channels, the hostname may need to be canonicalized to form a channel address, but that this is a problem outside of this part of the ssh architecture. Recently, I added a GSSAPIServiceName option to vintela-openssh that allows users to explicate the service name to use. A number of customers found this useful because they have DNS namespaces that look nothing like their realm namespace. A similar issue may arise from draft-ietf-krb-wg-kerberos-referrals. d On Thu, 25 Aug 2005, Jeffrey Hutzelman wrote: > On Wednesday, August 24, 2005 05:19:52 PM -0400 Sam Hartman > wrote: > > > Bill> IMHO, the main thing that matters for interoperability is > > Bill> the complete client system behavior rather than the behavior > > Bill> of the part of the system which is above the GSS *API* > > Bill> boundary. > > > > Bill> Given that this question is being looked at within GSSAPI, > > Bill> perhaps the best we can say for now is that if a client > > Bill> system implementing this specification is unable to securely > > Bill> determine which hostname and/or GSS target name to use, then > > Bill> it SHOULD NOT use this mechanism. > > > > > > Jeff, would you please draft text to be added in an rfc editor note to > > do this? > > Sure. I think we need a bit of background in addition to the simple > requirement Bill mentioned. I'll propose adding the following text to the end > of section 7.1 to address this issue: > > > Because the GSSAPI mechanism uses the targ_name to authenticate the > server's identity, it is important that it be determined in a secure > fashion. One common way to do this is to construct the targ_name > from the hostname as typed by the user; unfortunately, because some > GSSAPI mechanisms do not canonicalize hostnames, it is likely that > this technique will fail if the user has not typed a fully-qualified, > canonical hostname. Thus, implementors may wish to use other methods, > but should take care to insure they are secure. For example, one > should not rely on an unprotected DNS record to map a host alias to > the primary name of a server, or an IP address to a hostname, since > an attacker can modify the mapping and impersonate the server. > > Implementations of mechanisms conforming to this document MUST NOT use > the results of insecure DNS queries to construct the targ_name. Clients > MAY make use of a mapping provided by local configuration, append a > statically configured domain name to unqualified hostnames, and/or use > other secure means to determine the targ_name to be used. If a client > system is unable to securely determine which targ_name to use, then it > SHOULD NOT use this mechanism. > > > > > * Is Bill's solution a good idea > > I think Bill's solution is good, as far as it goes. The basic requirement is > that clients that cannot figure out what to do securely SHOULD NOT use this > mechanism. The text I proposed provides a little background on why, and also > adds the requirement that implementations MUST NOT use insecure DNS to decide > what hostname to use. Based on what I've seen in ssh implementations, I don't > expect that to be a difficult sell in this WG. > > > > > * Is it a requirement that we fix this hole > > I'm not sure that it is. RFC4120 provides very similar advice to what I > provided above, and it is my hope that the next GSSAPI revision will do the > same. On the other hand, there is the danger that if we don't call this out, > some implementor will think it is a good idea to reverse-resolve an address > provided by a user, which would be unfortunate. > > I think I'll mostly stay neutral on this question. > > > > > * Is Jeff's text good? > > Yes, I think my text is good. :-) > > > -- Jeff > > > -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 21:37:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8TAL-0007za-0I for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 21:37:57 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06626 for ; Thu, 25 Aug 2005 21:37:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A64263B2BE; Fri, 26 Aug 2005 01:37:53 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from fsau.vintela.com (unknown [202.183.100.57]) by mail.netbsd.org (Postfix) with ESMTP id 71D1A63B110 for ; Fri, 26 Aug 2005 01:37:52 +0000 (UTC) Received: from lark.vintela.com (lark.vintela.com [10.20.36.133]) by fsau.vintela.com (Postfix) with ESMTP id 7909D32E3D; Fri, 26 Aug 2005 11:37:54 +1000 (EST) Date: Fri, 26 Aug 2005 11:37:51 +1000 (EST) From: David Leonard X-X-Sender: davidl@lark.vintela.com To: Jeffrey Hutzelman Cc: Sam Hartman , Bill Sommerfeld , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments In-Reply-To: Message-ID: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> Organization: Vintela; Quest Software MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, 26 Aug 2005, David Leonard wrote: > I propose instead for 7.1 that a client system SHOULD first construct > targ_name = "host@"+hostname (without modifying the user-supplied > hostname) and try GSS. Then, if the GSS fails [?], the application > SHOULD try canonicalizing the hostname and construct targ_name2 = > "host@"+canonicalize(hostname) and try that instead (if it's a > different string). and by 'canonicalize' i mean securely canonicalize, and only if such secure canonicalization is available. (i.e. as discussed) d -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 25 22:38:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8U7O-0008Sl-EK for secsh-archive@megatron.ietf.org; Thu, 25 Aug 2005 22:38:58 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09028 for ; Thu, 25 Aug 2005 22:38:56 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E96FF63B350; Fri, 26 Aug 2005 02:38:53 +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 05DC163B110 for ; Fri, 26 Aug 2005 02:38:53 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3D7C9E0049; Thu, 25 Aug 2005 22:38:49 -0400 (EDT) To: David Leonard Cc: Jeffrey Hutzelman , Bill Sommerfeld , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> From: Sam Hartman Date: Thu, 25 Aug 2005 22:38:49 -0400 In-Reply-To: (David Leonard's message of "Fri, 26 Aug 2005 11:33:17 +1000 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is your only objection to the claim that implementations may append a static string to the hostname? If so, let's remove that text. If not, please explain yourself and provide alternate text. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 26 02:58:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8YAu-0007i4-RX for secsh-archive@megatron.ietf.org; Fri, 26 Aug 2005 02:58:53 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01358 for ; Fri, 26 Aug 2005 02:58:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 419DC63B4FB; Fri, 26 Aug 2005 06:58:47 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from fsau.vintela.com (unknown [202.183.100.57]) by mail.netbsd.org (Postfix) with ESMTP id 0576E63B4F0 for ; Fri, 26 Aug 2005 06:58:46 +0000 (UTC) Received: from lark.vintela.com (lark.vintela.com [10.20.36.133]) by fsau.vintela.com (Postfix) with ESMTP id 21CD732E3E; Fri, 26 Aug 2005 16:58:45 +1000 (EST) Date: Fri, 26 Aug 2005 16:58:44 +1000 (EST) From: David Leonard X-X-Sender: davidl@lark.vintela.com To: Sam Hartman Cc: Jeffrey Hutzelman , Bill Sommerfeld , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments In-Reply-To: Message-ID: References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> Organization: Vintela; Quest Software MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 25 Aug 2005, Sam Hartman wrote: > Is your only objection to the claim that implementations may append a > static string to the hostname? To the unqualified hostnames? yes, I think so. Even case folding in some security schemes might be a problem in unicode cases. Though, I'm not sure about this. RFC2742 s4.1 (to which this I-D's s7.1 refers) suggests that the mechanism may do folding/canonicalizing. This thread has been mostly about what SSH clients should do for older GSS implementations, of which I am not expert. > If not, please explain yourself and > provide alternate text. I will suggest this text to add to 7.1: An implementation SHOULD NOT perform any modifications or canonicalization of the hostname when constructing the targ_name. The intent is to prevent the client canonicalization of the user's hostname from inadvertently interfering with the intended service determination made by a GSS mechanism. But, to fulfil interoperability objectives of the RFC 4120 s1.3 ilk this text would also have to be added. To maximize interoperability, an implementation SHOULD fold the hostname to lowercase before constructing targ_name. If a mechanism described in this document subsequently fails AND a secure method of canonicalization is available, an implementation SHOULD re-attempt the mechanism using a targ_name constructed from the securely-canonicalized hostname. Secure methods of canonicalization include appending statically configured domains to unqualified hostnames, and secure DNS. Now, I'm not 100% happy with this compromise approach (the second suggested para), because 're-attempt' really means 'reconnect', which is bad. I'm open to other ideas because I'm unsure about this. d -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 26 12:54:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hT9-00009h-Op for secsh-archive@megatron.ietf.org; Fri, 26 Aug 2005 12:54:20 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01548 for ; Fri, 26 Aug 2005 12:54:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6780463B11B; Fri, 26 Aug 2005 16:54:14 +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 19D1063B17A for ; Fri, 26 Aug 2005 16:54:13 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C155E0049; Fri, 26 Aug 2005 12:54:07 -0400 (EDT) To: David Leonard Cc: Jeffrey Hutzelman , Bill Sommerfeld , ietf-ssh@NetBSD.org, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Subject: Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments References: <7673A0F0198AF89468B0F982@bistromath.pc.cs.cmu.edu> <1124733504.24824.191.camel@thunk> From: Sam Hartman Date: Fri, 26 Aug 2005 12:54:06 -0400 In-Reply-To: (David Leonard's message of "Fri, 26 Aug 2005 16:58:44 +1000 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "David" == David Leonard writes: David> On Thu, 25 Aug 2005, Sam Hartman wrote: >> Is your only objection to the claim that implementations may >> append a static string to the hostname? David> To the unqualified hostnames? yes, I think so. Even case David> folding in some security schemes might be a problem in David> unicode cases. Though, I'm not sure about this. RFC2742 David> s4.1 (to which this I-D's s7.1 refers) suggests that the David> mechanism may do folding/canonicalizing. This thread has David> been mostly about what SSH clients should do for older GSS David> implementations, of which I am not expert. OK. >> If not, please explain yourself and provide alternate text. David> I will suggest this text to add to 7.1: David> An implementation SHOULD NOT perform any modifications or David> canonicalization of the hostname when constructing the David> targ_name. This proposed text does not actually address Bill's original concern: it does not give implementation advice in the case where the implementation cannot figure out what to do. The implementation advice we're trying to give is to not use mechanisms described in the draft in that case. As such I'm going to adopt Jeff's text without the recommendation of appending a static hostname or discussing case folding. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 27 12:14:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E93KH-00010c-Kt for secsh-archive@megatron.ietf.org; Sat, 27 Aug 2005 12:14:37 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19596 for ; Sat, 27 Aug 2005 12:14:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B452563B136; Sat, 27 Aug 2005 16:14:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from web53508.mail.yahoo.com (web53508.mail.yahoo.com [206.190.37.69]) by mail.netbsd.org (Postfix) with SMTP id B06B263B102 for ; Sat, 27 Aug 2005 16:14:30 +0000 (UTC) Received: (qmail 851 invoked by uid 60001); 27 Aug 2005 16:07:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DcBCRulKZIs1rftl5HHMNpb37lAcZg/LLrbYZVd4nk6um70FjUmD3CSJcfF22kM9S/fqkV5XB2QRTu/aOItYazrbX4AzscXupqHEBNKLEiv8beq2RuRdyfcbiWK/wCkRAekqUtTzATT0GO8+KweOlhCKzqKacoOn9LcITo7zfl4= ; Message-ID: <20050827160750.849.qmail@web53508.mail.yahoo.com> Received: from [24.225.72.205] by web53508.mail.yahoo.com via HTTP; Sat, 27 Aug 2005 09:07:50 PDT Date: Sat, 27 Aug 2005 09:07:50 -0700 (PDT) From: Eric Brown Subject: draft-ietf-secsh-filexfer-09 To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I've been reviewing draft-ietf-secsh-filexfer-09 and noticed the space-available extended message has a reply that doesn't identify the message. All other extended messages identify the extended message type as the first string in the packet. This space-available packet makes it difficult to implement in my client and also makes it inconsistent. byte SSH_FXP_EXTENDED uint32 request-id string "space-available" string path [UTF-8] byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint64 bytes-on-device uint64 unused-bytes-on-device uint64 bytes-available-to-user uint64 unused-bytes-available-to-user uint32 bytes-per-allocation-unit __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 27 12:20:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E93Pr-0002bj-1M for secsh-archive@megatron.ietf.org; Sat, 27 Aug 2005 12:20:23 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19788 for ; Sat, 27 Aug 2005 12:20:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 37E2F63B13F; Sat, 27 Aug 2005 16:20:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from web53509.mail.yahoo.com (web53509.mail.yahoo.com [206.190.37.70]) by mail.netbsd.org (Postfix) with SMTP id 3A8B363B102 for ; Sat, 27 Aug 2005 16:20:19 +0000 (UTC) Received: (qmail 91191 invoked by uid 60001); 27 Aug 2005 16:13:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C/T0twbnJRWIvYGszYY7qnxebvlJuWJKB9+Ke5fCEpc2pw3YvFtxRpS4ZbI/dwUgT33bYSsl2EBDS8EmLqL9dgGYbMPwg4QQXW3T0JzcBG+tUito7t1CNhC6C5j6M54jVMCS89vJRBAg5l6A0EO3mhCaww5R7O+c4+xpj0D3PxY= ; Message-ID: <20050827161337.91189.qmail@web53509.mail.yahoo.com> Received: from [24.225.72.205] by web53509.mail.yahoo.com via HTTP; Sat, 27 Aug 2005 09:13:37 PDT Date: Sat, 27 Aug 2005 09:13:37 -0700 (PDT) From: Eric Brown Subject: New draft possibilities To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I was just wondering if there has ever been any thought put to making a draft of a UDP tunnel like the TCP forwarding function. Also it would be nice to have a draft on process management. A client could get a list of processes, start or stop them, and get detailed properties on them. Just some thoughts. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 27 17:11:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E97xR-0003qp-TQ for secsh-archive@megatron.ietf.org; Sat, 27 Aug 2005 17:11:22 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00298 for ; Sat, 27 Aug 2005 17:11:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2897863B12D; Sat, 27 Aug 2005 21:11:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 76E8263B11B for ; Sat, 27 Aug 2005 21:11:14 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7817295; Sat, 27 Aug 2005 15:11:13 -0600 Message-ID: <4310D8D7.2020903@vandyke.com> Date: Sat, 27 Aug 2005 15:19:19 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Eric Brown CC: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-filexfer-09 References: <20050827160750.849.qmail@web53508.mail.yahoo.com> In-Reply-To: <20050827160750.849.qmail@web53508.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Eric Brown wrote: > I've been reviewing draft-ietf-secsh-filexfer-09 and > noticed the space-available extended message has a > reply > that doesn't identify the message. All other extended > messages identify the extended message type as the > first string in the packet. This space-available > packet makes it difficult to implement in my client > and also makes it inconsistent. > byte SSH_FXP_EXTENDED > uint32 request-id > string "space-available" > string path [UTF-8] > > byte SSH_FXP_EXTENDED_REPLY > uint32 request-id > uint64 bytes-on-device > uint64 unused-bytes-on-device > uint64 bytes-available-to-user > uint64 unused-bytes-available-to-user > uint32 bytes-per-allocation-unit Argh... The request-id should be sufficient to match up the request with the response... I don't understand why people need the string in the reply as well .... Oh well... What is peoples status on shipping SFTP v6 support? I know we've got people using the vendor-id and supported2 extensions already. Has anyone shipped support for this request yet? How about other portions of the draft? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Aug 28 09:48:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9NW6-0004pH-Ox for secsh-archive@megatron.ietf.org; Sun, 28 Aug 2005 09:48:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18982 for ; Sun, 28 Aug 2005 09:48:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1A46963B2E1; Sun, 28 Aug 2005 13:48:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id D77BE63B2CE for ; Sun, 28 Aug 2005 13:48:04 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA10592; Sun, 28 Aug 2005 09:48:04 -0400 (EDT) From: der Mouse Message-Id: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 28 Aug 2005 09:36:05 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Filename : draft-ietf-secsh-publickey-subsystem-03.txt This looks good. I do see a few copy-edit details, whch I shall leave it up to others to decide on the actual importance of: Lines 242-244: The version packet, as well as all requests and responses described in Section 3 are a description of the 'name' field and the data part of the packet. s/3/3,/ Line 304: SHOULD be sent. Note that normally, status messages are only sent by s/only sent by/sent by only/ Line 367: SSH_PUBLICKEY_ACCESS_DENIED s/$/./ Lines 372-375: SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. That "requires" looks subjectless; strictly, it appears to refer back to "storage" eight words earlier, but that reads nonsensically. While I think the meaning is clear, I'm not confident non-anglophones will find it as clear as I do; you might want to reword it. Suggestion: SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a mandatory attribute, mere storage of the attribute is not sufficient; the server must understand and implement the intent of the attribute. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Aug 28 09:50:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9NYH-0005Nc-7g for secsh-archive@megatron.ietf.org; Sun, 28 Aug 2005 09:50:25 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19079 for ; Sun, 28 Aug 2005 09:50:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B972463B2E4; Sun, 28 Aug 2005 13:49:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6E70263B2CE for ; Sun, 28 Aug 2005 13:49:43 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA10614; Sun, 28 Aug 2005 09:49:38 -0400 (EDT) From: der Mouse Message-Id: <200508281349.JAA10614@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 28 Aug 2005 09:48:32 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: publickey-subsystem-03: extending last call by a week. In-Reply-To: <1124927822.7308.361.camel@thunk> References: <1124927822.7308.361.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Title : Secure Shell Public-Key Subsystem >> Author(s) : J. Galbraith, et al. >> Filename : draft-ietf-secsh-publickey-subsystem-03.txt >> Pages : 19 >> Date : 2005-8-24 > der Mouse: is this revision acceptable to you? Yes. There are a few niggling copy-edit details (I just sent mail to the list about them), but I'd be satisfied with it even if those don't get fixed. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Aug 28 16:50:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9U6V-0006Gk-P6 for secsh-archive@megatron.ietf.org; Sun, 28 Aug 2005 16:50:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11020 for ; Sun, 28 Aug 2005 16:50:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C1C2863B38E; Sun, 28 Aug 2005 20:49:29 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 7551F63B3D8 for ; Sun, 28 Aug 2005 20:49:28 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA11684; Sun, 28 Aug 2005 16:49:27 -0400 (EDT) From: der Mouse Message-Id: <200508282049.QAA11684@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 28 Aug 2005 16:32:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call on draft-ietf-secsh-publickey-subsystem-02 In-Reply-To: <430B4308.6030409@siliconcircus.com> References: <3EF96AF20489A34296050FBD5C36ECB91883AB@beacon.PSC.process.com> <1123694868.10124.24.camel@thunk> <200508102207.SAA07620@Sparkle.Rodents.Montreal.QC.CA> <430B4308.6030409@siliconcircus.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> [various minor criticisms of publickey-subsystem-02] > [replies] Looks good; see my comments on publickey-subsystem-03 for more. >> There also is no provision for cases such as imposing certain hosts' >> presence or absence in (say) the "agent" list. > I presume you mean the "from" list? I actually meant the agent list, but it was just an example; similar remarks apply to the from list. > For presence, I again don't see the case where an admin wants this. Neither do I, but I'm not confident there are none. I suppose, though, that anyone who has such desires will probably be ready to ignore anything in the spec that seems to forbid that. >> In 5.2.1, there is a restriction in that the length limit applies >> even to domain-localized names. This seems semi-broken, since FQDNs >> can be relatively long (though 64 seems generous now, I have little >> confidence it will remain so - I already have a private name 43 >> characters long). > You also have one 22 characters long, though > (rodents.montreal.qc.ca). By "private name" I meant a domain-localized name. The longest name I have in use is fixed-forwarded-tcpip@rodents.montreal.qc.ca, which is 44 characters long (43 was probably a mistake on my part). 64 is probably safe for the foreseeable future, though I am put in mind of etdomenenavnkanmaksimaltinneholdesekstitrebokstaversliksomdette.com (which is already 67 characters long). While its holder(s) probably aren't working on ssh, and obviously chose the name for its length (given the meaning), it's still already over the limit. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 08:39:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ivQ-0000u2-RX for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 08:39:45 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05342 for ; Mon, 29 Aug 2005 08:39:42 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4EE8463B2DA; Mon, 29 Aug 2005 12:39:38 +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 66C2D63B242 for ; Mon, 29 Aug 2005 12:39:37 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: draft-ietf-secsh-filexfer-09 Date: Mon, 29 Aug 2005 08:42:07 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188416@beacon.PSC.process.com> Thread-Topic: draft-ietf-secsh-filexfer-09 Thread-Index: AcWrTDttzJcl8LxgR/6FQbM8RYOyrwBSnEVQ From: "Richard Whalen" To: "Joseph Galbraith" , "Eric Brown" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On > Behalf Of Joseph Galbraith > Sent: Saturday, August 27, 2005 5:19 PM > To: Eric Brown > Cc: ietf-ssh@netbsd.org > Subject: Re: draft-ietf-secsh-filexfer-09 >=20 >=20 > Eric Brown wrote: > > I've been reviewing draft-ietf-secsh-filexfer-09 and > > noticed the space-available extended message has a > > reply > > that doesn't identify the message. All other extended > > messages identify the extended message type as the > > first string in the packet. This space-available > > packet makes it difficult to implement in my client > > and also makes it inconsistent. > > byte SSH_FXP_EXTENDED > > uint32 request-id > > string "space-available" > > string path [UTF-8] > >=20 > > byte SSH_FXP_EXTENDED_REPLY > > uint32 request-id > > uint64 bytes-on-device > > uint64 unused-bytes-on-device > > uint64 bytes-available-to-user > > uint64 unused-bytes-available-to-user > > uint32 bytes-per-allocation-unit >=20 > Argh... >=20 > The request-id should be sufficient to match up the request > with the response... I don't understand why people need > the string in the reply as well .... >=20 > Oh well... >=20 > What is peoples status on shipping SFTP v6 support? >=20 > I know we've got people using the vendor-id and supported2 > extensions already. >=20 > Has anyone shipped support for this request yet? >=20 > How about other portions of the draft? >=20 > Thanks, >=20 > Joseph >=20 I have this extension coded in our latest server, our client currently does not make any use of it. The server is version 4, and it also encodes the vendor-id and supported2 extensions in the FXP_VERSION packet. If the response were to change it would be possible to use the vendor-id in future implementations of the client to determine which format might be in use. Since this packet has a fixed length, it may be possible to determine which version of the response is in use by the length of the packet. That said, I'd rather that it didn't change. Though I have coded many of our private extensions to include the extension name in the reply, it is not necessary as the client keeps track of the extension name in the data structure that keeps track of outstanding client requests. ---------------------- Richard Whalen Process Software From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 13:44:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ngI-0001qd-Od for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:44:27 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23178 for ; Mon, 29 Aug 2005 13:44:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DE1A563B48C; Mon, 29 Aug 2005 17:43:38 +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 22C1663B459 for ; Mon, 29 Aug 2005 17:43:36 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7THhXHT025111; Mon, 29 Aug 2005 10:43:33 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7THhXUj014430; Mon, 29 Aug 2005 13:43:33 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7THhWHD000503; Mon, 29 Aug 2005 13:43:32 -0400 (EDT) Subject: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Cc: Tadayoshi Kohno Content-Type: text/plain Message-Id: <1125337411.453.8.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 29 Aug 2005 13:43:32 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Some review comments from Russ Housley. As a strawman resolution to the DISCUSS comment, how about making aes128-ctr REQUIRED? (this new requirement has no effect on implementations which don't claim to implement newmodes). I haven't looked closely at the non-DISCUSS comments just yet. - Bill -----Forwarded Message----- From: Russ Housley Subject: DISCUSS: draft-ietf-secsh-newmodes-05 Sender: iesg-bounces@ietf.org To: iesg@ietf.org SSH Transport Layer Encryption Modes (Proposed Standard) DISCUSS All of the encryption modes described in this document are RECOMMENDED or OPTIONAL. Why isn't one of them REQUIRED? COMMENT I think that the last paragraph of the Abstract belongs in the Introduction. Section 3.1 says: > > The preferred way to do this is to rekey after receiving more than > 2**31 packets since the last rekey operation. > I suggest: > > The preferred implementation technique is to use the reception of > more than 2**31 packets since the last rekey operation as a trigger > to rekey. Two comments about section 4: * The description of counter mode seems compatible with NIST SP 800-38A. A single counter is used here, instead of a counter for each packet, but that does not seem to be a problem. Please reference NIST SP 800-38A. * The usual reference for Triple-DES is: [3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998. Section 6.2 says: > > Fortunately, the common concerns with counter mode do not apply to > SSH because of the rekeying recommendations and because of the > additional protection provided by the transport protocol's MAC. > This sentence should also include the built-in initial key establishment capability. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 13:46:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nif-0002Cz-5P for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:46:53 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23288 for ; Mon, 29 Aug 2005 13:46:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B235863B2F3; Mon, 29 Aug 2005 17:46:49 +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 F153263B2DE for ; Mon, 29 Aug 2005 17:46:48 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7THkmTW017695; Mon, 29 Aug 2005 11:46:48 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7THkmUj015715; Mon, 29 Aug 2005 13:46:48 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7THklwg000514; Mon, 29 Aug 2005 13:46:47 -0400 (EDT) Subject: Re: New draft possibilities From: Bill Sommerfeld To: Eric Brown Cc: ietf-ssh@NetBSD.org In-Reply-To: <20050827161337.91189.qmail@web53509.mail.yahoo.com> References: <20050827161337.91189.qmail@web53509.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1125337606.453.15.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 29 Aug 2005 13:46:47 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Sat, 2005-08-27 at 12:13, Eric Brown wrote: > I was just wondering if there has ever been any > thought put to making a draft of a UDP tunnel like the > TCP forwarding function. This has been suggested before several times. nobody has stepped forward to write a draft. Are you volunteering to write one? > Also it would be nice to have a draft on process > management. A client could get a list of processes, > start or stop them, and get detailed properties on > them. I've not seen this suggestion before. I'd put higher priority on finding a volunteer to finish the Agent draft first... - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 14:07:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9o2F-0005qU-1p for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:07:07 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24498 for ; Mon, 29 Aug 2005 14:07:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C44D163B30C; Mon, 29 Aug 2005 18:07:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 16FBA63B2DE for ; Mon, 29 Aug 2005 18:07:03 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1E9o29-0007dV-00; Mon, 29 Aug 2005 19:07:01 +0100 From: Ben Harris To: sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] In-Reply-To: <1125337411.453.8.camel@thunk> References: <1125337411.453.8.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Mon, 29 Aug 2005 19:07:01 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1125337411.453.8.camel@thunk> you write: >Some review comments from Russ Housley. ... >>DISCUSS >> >> All of the encryption modes described in this document are RECOMMENDED >> or OPTIONAL. Why isn't one of them REQUIRED? ... >As a strawman resolution to the DISCUSS comment, how about making >aes128-ctr REQUIRED? (this new requirement has no effect on >implementations which don't claim to implement newmodes). I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH implementations are required to have 3DES code around anyway to support 3des-cbc, so anyone implementing newmodes can put in 3des-ctr support trivially, whereas aes128-ctr might be a lot more effort or even impossible (imagine a small implementation without room for both 3DES and AES). This does raise the question of how to arrange a transition to AES (or whatever) in the longer term, but I don't think it should be done on the back of newmodes. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 14:16:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oB9-0008UN-UO for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:16:19 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24932 for ; Mon, 29 Aug 2005 14:16:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DA63563B2ED; Mon, 29 Aug 2005 18:16:08 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id DF3EB63B19C for ; Mon, 29 Aug 2005 18:16:07 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13067; 29 Aug 2005 14:15 EDT Date: Mon, 29 Aug 2005 14:15:24 -0400 From: Jeffrey Hutzelman To: Ben Harris , sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] Message-ID: In-Reply-To: References: <1125337411.453.8.camel@thunk> Originator-Info: login-token=Mulberry:01ZwuxNNFzJqizVim1monho/596F/uPyrUgN+ZnYs=; 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 Content-Transfer-Encoding: 7bit On Monday, August 29, 2005 07:07:01 PM +0100 Ben Harris wrote: > In article <1125337411.453.8.camel@thunk> you write: >> Some review comments from Russ Housley. > ... >>> DISCUSS >>> >>> All of the encryption modes described in this document are RECOMMENDED >>> or OPTIONAL. Why isn't one of them REQUIRED? > ... >> As a strawman resolution to the DISCUSS comment, how about making >> aes128-ctr REQUIRED? (this new requirement has no effect on >> implementations which don't claim to implement newmodes). > > I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH > implementations are required to have 3DES code around anyway to support > 3des-cbc, so anyone implementing newmodes can put in 3des-ctr support > trivially, whereas aes128-ctr might be a lot more effort or even > impossible (imagine a small implementation without room for both 3DES and > AES). > > This does raise the question of how to arrange a transition to AES (or > whatever) in the longer term, but I don't think it should be done on the > back of newmodes. Russ's comment notwithstanding, I don't think we actually need any of the modes described in newmodes to be REQUIRED. It's one thing to say "if you support ssh then you MUST support 3des-cbc". It's quite another to say "if you support 3des-ctr then you MUST also support aes128-ctr" or vice versa. The former insures that ssh implementations will be interoperable; the latter does not appear to me to add any value. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 14:27:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oLg-000273-20 for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:27:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25861 for ; Mon, 29 Aug 2005 14:27:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8D28463B2F4; Mon, 29 Aug 2005 18:27:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id 0556263B19C for ; Mon, 29 Aug 2005 18:27:08 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AFDDEE0049; Mon, 29 Aug 2005 14:26:34 -0400 (EDT) To: sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org Subject: Added rfc-editor note to break draft From: Sam Hartman Date: Mon, 29 Aug 2005 14:26:34 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi. The break draft is on this week's IESG agenda for review and possible approval. One of the ADs noted that the first reference to the ssh channel protocol is unqualified. I added an RFC editor note (instructions to rfc editor on textual changes to apply during publication) adding such a reference. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 14:41:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oZo-00067F-ML for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:41:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26968 for ; Mon, 29 Aug 2005 14:41:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0040C63B466; Mon, 29 Aug 2005 18:41:45 +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 566CB63B303 for ; Mon, 29 Aug 2005 18:41:44 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7TIfdDB000628; Mon, 29 Aug 2005 12:41:39 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7TIfcWB013907; Mon, 29 Aug 2005 14:41:38 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7TIfcQK001215; Mon, 29 Aug 2005 14:41:38 -0400 (EDT) Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: Ben Harris , ietf-ssh@NetBSD.org In-Reply-To: References: <1125337411.453.8.camel@thunk> Content-Type: text/plain Message-Id: <1125340897.453.41.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 29 Aug 2005 14:41:38 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-08-29 at 14:15, Jeffrey Hutzelman wrote: > Russ's comment notwithstanding, I don't think we actually need any of the > modes described in newmodes to be REQUIRED. It's one thing to say "if you > support ssh then you MUST support 3des-cbc". It's quite another to say "if > you support 3des-ctr then you MUST also support aes128-ctr" or vice versa. I believe the goal is "if you support 'newmodes' you must support aes128-ctr" so that two implementations which claim to support "newmodes" will not fail to interoperate because one only supports 3des-ctr and the other only supports aes128-ctr. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 15:00:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ord-0003K7-Kr for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:00:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28368 for ; Mon, 29 Aug 2005 15:00:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DA62463B4A4; Mon, 29 Aug 2005 18:59:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 37FA363B303 for ; Mon, 29 Aug 2005 18:59:58 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA02883; Mon, 29 Aug 2005 14:59:57 -0400 (EDT) From: der Mouse Message-Id: <200508291859.OAA02883@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 29 Aug 2005 14:54:09 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] In-Reply-To: <1125340897.453.41.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125340897.453.41.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> I don't think we actually need any of the modes described in >> newmodes to be REQUIRED. [...] > I believe the goal is "if you support 'newmodes' you must support > aes128-ctr" so that two implementations which claim to support > "newmodes" will not fail to interoperate because one only supports > 3des-ctr and the other only supports aes128-ctr. I don't see that as an especially useful property, because I don't think "supports `newmodes'" is a useful thing. "Supports aes128-ctr from `newmodes'", or "rekeys as recommended by `newmodes'", or the like, those could be useful, but newmodes qua newmodes isn't so much a thing to be supported (or not) as a convenient umbrella under which to collect a bunch of individual things to be supported (or not). I'm in favour of the "no REQUIRED items" position. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 15:02:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9otn-0003kY-8B for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:02:27 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28509 for ; Mon, 29 Aug 2005 15:02:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 47A1063B475; Mon, 29 Aug 2005 19:02:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 2EFEC63B474 for ; Mon, 29 Aug 2005 19:02:23 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA02923; Mon, 29 Aug 2005 15:02:22 -0400 (EDT) From: der Mouse Message-Id: <200508291902.PAA02923@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 29 Aug 2005 15:00:26 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities In-Reply-To: <1125337606.453.15.camel@thunk> References: <20050827161337.91189.qmail@web53509.mail.yahoo.com> <1125337606.453.15.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I'd put higher priority on finding a volunteer to finish the Agent > draft first... Has it been orphaned? I had assumed its authors were still working on it (albeit apparently not terribly urgently). I can pick it up and see what I can do with it, if that would be considered a Good Thing. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 15:16:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9p7A-0006oa-4Y for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:16:16 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29879 for ; Mon, 29 Aug 2005 15:16:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A2C1A63B478; Mon, 29 Aug 2005 19:15:52 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id DC1BA63B476 for ; Mon, 29 Aug 2005 19:15:50 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 16E14E0049; Mon, 29 Aug 2005 15:15:16 -0400 (EDT) To: Jeffrey Hutzelman Cc: Ben Harris , sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] References: <1125337411.453.8.camel@thunk> From: Sam Hartman Date: Mon, 29 Aug 2005 15:15:16 -0400 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 29 Aug 2005 14:15:24 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Monday, August 29, 2005 07:07:01 PM +0100 Ben Harris Jeffrey> wrote: >> In article <1125337411.453.8.camel@thunk> you write: >>> Some review comments from Russ Housley. >> ... >>>> DISCUSS >>>> >>>> All of the encryption modes described in this document are >>>> RECOMMENDED or OPTIONAL. Why isn't one of them REQUIRED? >> ... >>> As a strawman resolution to the DISCUSS comment, how about >>> making aes128-ctr REQUIRED? (this new requirement has no >>> effect on implementations which don't claim to implement >>> newmodes). >> I'd prefer to make 3des-ctr the REQUIRED algorithm, since all >> SSH implementations are required to have 3DES code around >> anyway to support 3des-cbc, so anyone implementing newmodes can >> put in 3des-ctr support trivially, whereas aes128-ctr might be >> a lot more effort or even impossible (imagine a small >> implementation without room for both 3DES and AES). >> >> This does raise the question of how to arrange a transition to >> AES (or whatever) in the longer term, but I don't think it >> should be done on the back of newmodes. Jeffrey> Russ's comment notwithstanding, I don't think we actually Jeffrey> need any of the modes described in newmodes to be Jeffrey> REQUIRED. It's one thing to say "if you support ssh then Jeffrey> you MUST support 3des-cbc". It's quite another to say Jeffrey> "if you support 3des-ctr then you MUST also support Jeffrey> aes128-ctr" or vice versa. The former insures that ssh Jeffrey> implementations will be interoperable; the latter does Jeffrey> not appear to me to add any value. I tend to agree with Jeff. Note that Russ asked a question; he did not yet ask for a change. I think someone should answer his question. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 15:16:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9p7T-0006rC-UO for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:16:35 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29924 for ; Mon, 29 Aug 2005 15:16:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BCDF363B29E; Mon, 29 Aug 2005 19:16:11 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id EC8A263B200 for ; Mon, 29 Aug 2005 19:16:10 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13110; 29 Aug 2005 15:15 EDT Date: Mon, 29 Aug 2005 15:15:46 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] Message-ID: <8394D64FC7851FB949BD07E1@sirius.fac.cs.cmu.edu> In-Reply-To: <200508291859.OAA02883@Sparkle.Rodents.Montreal.QC.CA> References: <1125337411.453.8.camel@thunk> <1125340897.453.41.camel@thunk> <200508291859.OAA02883@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01EnrGrHziOyBexT4tRfj2G6ns/deZrj9/7/QRSPo=; 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 Content-Transfer-Encoding: 7bit On Monday, August 29, 2005 02:54:09 PM -0400 der Mouse wrote: >>> I don't think we actually need any of the modes described in >>> newmodes to be REQUIRED. [...] >> I believe the goal is "if you support 'newmodes' you must support >> aes128-ctr" so that two implementations which claim to support >> "newmodes" will not fail to interoperate because one only supports >> 3des-ctr and the other only supports aes128-ctr. > > I don't see that as an especially useful property, because I don't > think "supports `newmodes'" is a useful thing. "Supports aes128-ctr > from `newmodes'", or "rekeys as recommended by `newmodes'", or the > like, those could be useful, but newmodes qua newmodes isn't so much a > thing to be supported (or not) as a convenient umbrella under which to > collect a bunch of individual things to be supported (or not). Exactly. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 15:52:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pgY-0006qC-4L for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:52:50 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03193 for ; Mon, 29 Aug 2005 15:52:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E0E0563B3AE; Mon, 29 Aug 2005 19:52:46 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 2B23363B2C7 for ; Mon, 29 Aug 2005 19:52:46 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13141; 29 Aug 2005 15:52 EDT Date: Mon, 29 Aug 2005 15:52:33 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: New draft possibilities Message-ID: In-Reply-To: <200508291902.PAA02923@Sparkle.Rodents.Montreal.QC.CA> References: <20050827161337.91189.qmail@web53509.mail.yahoo.com> <1125337606.453.15.camel@thunk> <200508291902.PAA02923@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01qUxhTBO01sD1l9nN3MqRu0C+mHcwgNoWwY+x38w=; 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 Content-Transfer-Encoding: 7bit On Monday, August 29, 2005 03:00:26 PM -0400 der Mouse wrote: >> I'd put higher priority on finding a volunteer to finish the Agent >> draft first... > > Has it been orphaned? I had assumed its authors were still working on > it (albeit apparently not terribly urgently). > > I can pick it up and see what I can do with it, if that would be > considered a Good Thing. I certainly think it would be a good idea. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 16:06:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9puC-0000be-Ti for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 16:06:57 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03670 for ; Mon, 29 Aug 2005 16:06:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 03FBD63B47E; Mon, 29 Aug 2005 20:06:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 54AC463B3D9 for ; Mon, 29 Aug 2005 20:06:50 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7820763; Mon, 29 Aug 2005 14:06:49 -0600 Message-ID: <43136CC4.5020403@vandyke.com> Date: Mon, 29 Aug 2005 14:15:00 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: der Mouse , ietf-ssh@NetBSD.org Subject: Re: New draft possibilities References: <20050827161337.91189.qmail@web53509.mail.yahoo.com> <1125337606.453.15.camel@thunk> <200508291902.PAA02923@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > > > On Monday, August 29, 2005 03:00:26 PM -0400 der Mouse > wrote: > >>> I'd put higher priority on finding a volunteer to finish the Agent >>> draft first... >> >> Has it been orphaned? I had assumed its authors were still working on >> it (albeit apparently not terribly urgently). >> >> I can pick it up and see what I can do with it, if that would be >> considered a Good Thing. > > I certainly think it would be a good idea. Ditto. More power to you. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 16:32:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9qIb-0005qK-Be for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 16:32:09 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04913 for ; Mon, 29 Aug 2005 16:32:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B4DB263B2E1; Mon, 29 Aug 2005 20:32:05 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6EEBC63B2C7 for ; Mon, 29 Aug 2005 20:32:04 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA07431; Mon, 29 Aug 2005 16:32:03 -0400 (EDT) From: der Mouse Message-Id: <200508292032.QAA07431@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 29 Aug 2005 16:25:13 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] In-Reply-To: References: <1125337411.453.8.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Note that Russ asked a question; he did not yet ask for a change. I > think someone should answer his question. True enough: >>>>> All of the encryption modes described in this document are >>>>> RECOMMENDED or OPTIONAL. Why isn't one of them REQUIRED? My own answer to it, then, which anyone is welcome to use if it seems appropriate, is: Because it's not appropriate; newmodes is not so much a thing to implement or conform to in its own right as it is a collection of individual things to implement or conform to. Thus, making (say) des3-ctr REQUIRED is really just saying "you cannot claim to do newmodes if you don't do des3-ctr", but since claiming to implement newmodes is not a useful thing (as opposed to claiming implementation of particular things defined in newmodes), this is not useful. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 16:39:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9qPF-0007fI-0N for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 16:39:01 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05243 for ; Mon, 29 Aug 2005 16:38:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5AD5D63B328; Mon, 29 Aug 2005 20:38:57 +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 AE3E063B31E for ; Mon, 29 Aug 2005 20:38:56 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7TKcp2B015427; Mon, 29 Aug 2005 13:38:51 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7TKcpUj003233; Mon, 29 Aug 2005 16:38:51 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7TKcoBP003482; Mon, 29 Aug 2005 16:38:50 -0400 (EDT) Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: Ben Harris , ietf-ssh@NetBSD.org In-Reply-To: References: <1125337411.453.8.camel@thunk> Content-Type: text/plain Message-Id: <1125347930.453.58.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 29 Aug 2005 16:38:50 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-08-29 at 14:15, Jeffrey Hutzelman wrote: > Russ's comment notwithstanding, I don't think we actually need any of the > modes described in newmodes to be REQUIRED. It's one thing to say "if you > support ssh then you MUST support 3des-cbc". It's quite another to say "if > you support 3des-ctr then you MUST also support aes128-ctr" or vice versa. > The former insures that ssh implementations will be interoperable; the > latter does not appear to me to add any value. The motivation for the counter-mode ciphers in newmodes is to avoid the known, but generally considered minor, security hole from the use of CBC with known IV values. I'd expect that users concerned with this attack will therefore want to move to a world where it is possible to disable CBC-mode ciphers. I think that, alone, justifies making one or more of the ciphers REQUIRED, to avoid a situation where two implementations would be required to fall back to 3des-cbc because neither implements the same counter-mode cipher. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 16:57:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9qgp-0002eR-Ah for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 16:57:11 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06141 for ; Mon, 29 Aug 2005 16:57:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 77DB263B31D; Mon, 29 Aug 2005 20:57:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 3AF2D63B28F for ; Mon, 29 Aug 2005 20:57:05 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA07633; Mon, 29 Aug 2005 16:57:04 -0400 (EDT) From: der Mouse Message-Id: <200508292057.QAA07633@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 29 Aug 2005 16:51:09 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] In-Reply-To: <1125347930.453.58.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125347930.453.58.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I'd expect that users concerned with this attack will therefore want > to move to a world where it is possible to disable CBC-mode ciphers. > I think that, alone, justifies making one or more of the ciphers > REQUIRED, to avoid a situation where two implementations would be > required to fall back to 3des-cbc because neither implements the same > counter-mode cipher. I don't see this as an issue. There's always the risk of not agreeing on a cipher; even if everyone were to pay attention to the REQUIREDs, admins can still tell implementations to refuse to use them. Furthermore, "a world where it is possible to disable CBC-mode ciphers" is what we already have. Certainly my implementation, and I think every other implementation I've looked at (all two? of them :), can be told to refuse to use any desired subset of the ciphers it implements, regardless of what any spec may name REQUIRED. Unless you mean "a world where it is practical to disable CBC-mode ciphers and still expect to interoperate with arm's-length third parties", in which case naming anything REQUIRED in newmodes won't do that unless you can also guarantee not only sufficiently universal implementation of newmodes but paying attention to that REQUIRED. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 16:59:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9qih-0002q3-Ey for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 16:59:08 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06232 for ; Mon, 29 Aug 2005 16:59:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3EA5B63B327; Mon, 29 Aug 2005 20:59:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 072E763B30B for ; Mon, 29 Aug 2005 20:59:02 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7TKx2TW022539 for ; Mon, 29 Aug 2005 14:59:02 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7TKx2Uj007977; Mon, 29 Aug 2005 16:59:02 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7TKx1Iu003566; Mon, 29 Aug 2005 16:59:02 -0400 (EDT) Subject: draft-ietf-secsh-dh-group-exchange has cleared the IESG. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1125349141.453.77.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 29 Aug 2005 16:59:01 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit draft-ietf-secsh-dh-group-exchange has been marked "Approved -- Announcement to be sent" in the IETF document tracker. A formal announcement should come out in a day or two. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 17:45:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9rRr-0004uA-Sd for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 17:45:47 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08459 for ; Mon, 29 Aug 2005 17:45:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B934863B336; Mon, 29 Aug 2005 21:45:43 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id C83BA63B28F for ; Mon, 29 Aug 2005 21:45:42 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E9rRl-0004GI-Ji; Mon, 29 Aug 2005 17:45:41 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Protocol Action: 'Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol' to Proposed Standard Message-Id: Date: Mon, 29 Aug 2005 17:45:41 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved the following document: - 'Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol ' as a Proposed Standard This document is the product of the Secure Shell Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-05.txt Technical Summary This document describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. Working Group Summary The SecSH Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 18:22:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9s1Y-0002Qw-0a for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 18:22:40 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15324 for ; Mon, 29 Aug 2005 18:22:37 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A9DD163B28F; Mon, 29 Aug 2005 22:22:36 +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 EA3C163B193 for ; Mon, 29 Aug 2005 22:22:35 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7TMMZHT027631 for ; Mon, 29 Aug 2005 15:22:35 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7TMMYWB012156; Mon, 29 Aug 2005 18:22:34 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7TMMYuM003853; Mon, 29 Aug 2005 18:22:34 -0400 (EDT) Subject: http://tools.ietf.org/wg/secsh "related documents" now match -ssh- drafts, too. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1125354154.3619.31.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 29 Aug 2005 18:22:34 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit FYI, the "related documents" section of the WG status page at http://tools.ietf.org/wg/secsh now includes individual submissions which have filenames matching -ssh- as well as the -secsh- it would get by default if there were any... (I asked Henrik Levkowetz if it would be possible earlier today; he made it happen almost immediately..) - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 18:50:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sS7-0001LL-7i for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 18:50:07 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16964 for ; Mon, 29 Aug 2005 18:50:04 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0AFAB63B3F8; Mon, 29 Aug 2005 22:50:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 1520A63B123 for ; Mon, 29 Aug 2005 22:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E9sS1-0000QF-Oc; Mon, 29 Aug 2005 18: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-scp-sftp-ssh-uri-03.txt Message-Id: Date: Mon, 29 Aug 2005 18:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Uniform Resource Identifier (URI) Scheme for Secure File Transfer Protocol (SFTP) and Secure Shell (SSH) Author(s) : S. Suehring, J. Salowey Filename : draft-ietf-secsh-scp-sftp-ssh-uri-03.txt Pages : 10 Date : 2005-8-29 This document describes the Uniform Resource Identifiers used to locate resources for the Secure File Transfer Protocol (SFTP) and the Secure Shell (SSH) protocols. The document describes the generic syntax involved in URI definitions as well as specific definitions for each protocol. These specific definitions may include user credentials such as username and also may include other parameters such as host key fingerprint. In addition, security considerations and examples are also provided within this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-03.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-scp-sftp-ssh-uri-03.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-scp-sftp-ssh-uri-03.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: <2005-8-29170405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-scp-sftp-ssh-uri-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-29170405.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 19:16:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9srJ-0000l2-Vd for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 19:16:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22210 for ; Mon, 29 Aug 2005 19:16:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E98F863B333; Mon, 29 Aug 2005 23:16:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 36C2263B243 for ; Mon, 29 Aug 2005 23:16:06 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13266; 29 Aug 2005 19:15 EDT Date: Mon, 29 Aug 2005 19:15:23 -0400 From: Jeffrey Hutzelman To: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: http://tools.ietf.org/wg/secsh "related documents" now match -ssh- drafts, too. Message-ID: <82F004AE79A7AD8F9F0774E3@sirius.fac.cs.cmu.edu> In-Reply-To: <1125354154.3619.31.camel@thunk> References: <1125354154.3619.31.camel@thunk> Originator-Info: login-token=Mulberry:01DYy4yXf0LT1Z1zBKQAroOKT+7/SUwDF6AeYuQww=; 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 Content-Transfer-Encoding: 7bit On Monday, August 29, 2005 06:22:34 PM -0400 Bill Sommerfeld wrote: > FYI, the "related documents" section of the WG status page at > http://tools.ietf.org/wg/secsh now includes individual submissions which > have filenames matching -ssh- as well as the -secsh- it would get by > default if there were any... > > (I asked Henrik Levkowetz if it would be possible earlier today; he made > it happen almost immediately..) Yeah; he responds that way a lot. :-) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 20:31:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9u2M-0006AC-8P for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 20:31:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26160 for ; Mon, 29 Aug 2005 20:31:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9691763B124; Tue, 30 Aug 2005 00:31:32 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by mail.netbsd.org (Postfix) with ESMTP id C0A0C63B101 for ; Tue, 30 Aug 2005 00:31:31 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from libra.cus.cam.ac.uk ([131.111.8.19]:39613) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1E9thS-000228-Ov (Exim 4.51) for ietf-ssh@NetBSD.org (return-path ); Tue, 30 Aug 2005 01:10:02 +0100 Received: from bjh21 (helo=localhost) by libra.cus.cam.ac.uk with local-esmtp (Exim 4.52) id 1E9thR-00062w-N4; Tue, 30 Aug 2005 01:10:01 +0100 Date: Tue, 30 Aug 2005 01:10:01 +0100 (BST) From: Ben Harris To: Bill Sommerfeld cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] In-Reply-To: <1125347930.453.58.camel@thunk> Message-ID: References: <1125337411.453.8.camel@thunk> <1125347930.453.58.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 29 Aug 2005, Bill Sommerfeld wrote: > The motivation for the counter-mode ciphers in newmodes is to avoid the > known, but generally considered minor, security hole from the use of CBC > with known IV values. > > I'd expect that users concerned with this attack will therefore want to > move to a world where it is possible to disable CBC-mode ciphers. > > I think that, alone, justifies making one or more of the ciphers > REQUIRED, to avoid a situation where two implementations would be > required to fall back to 3des-cbc because neither implements the same > counter-mode cipher. Making one of the ciphers REQUIRED, though, isn't sufficient to ensure that CBC-mode ciphers aren't used. To take a concrete example, PuTTY's preference order for AES is currently "aes256-ctr,aes256-cbc,aes192-ctr, aes192-cbc,aes128-ctr,aes128-cbc", so even though PuTTY supports aes128-ctr, it'll get aes256-cbc if the server supports that. To get the effect you want, you'd have to require clients to provide an option to prefer CTR-mode ciphers over CBC-mode (and presumably over other ciphers as well). As yet, the SSH drafts have avoided this kind of requirement on the configurability of clients, and I think this is probably a good thing. Incidentally, I'm not opposed to making 3des-ctr REQUIRED, for all that I think it's unnecessary. I _am_ opposed to making aes128-ctr REQUIRED. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 29 20:43:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9uDh-0007AQ-9F for secsh-archive@megatron.ietf.org; Mon, 29 Aug 2005 20:43:21 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26672 for ; Mon, 29 Aug 2005 20:43:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B9BD763B10D; Tue, 30 Aug 2005 00:43:18 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 014C363B101 for ; Tue, 30 Aug 2005 00:43:17 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13330; 29 Aug 2005 20:42 EDT Date: Mon, 29 Aug 2005 20:42:36 -0400 From: Jeffrey Hutzelman To: Ben Harris , Bill Sommerfeld cc: ietf-ssh@NetBSD.org Subject: Re: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05] Message-ID: In-Reply-To: References: <1125337411.453.8.camel@thunk> <1125347930.453.58.camel@thunk> Originator-Info: login-token=Mulberry:01xjBejDCY0wASe9YN+a6O+12ilbdNZNczpYzx/LA=; 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 Content-Transfer-Encoding: 7bit On Tuesday, August 30, 2005 01:10:01 AM +0100 Ben Harris wrote: > As yet, the SSH drafts have avoided this kind of requirement > on the configurability of clients, and I think this is probably a good > thing. I agree. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 01:05:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9yJK-0001j2-Vj for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 01:05:28 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07194 for ; Tue, 30 Aug 2005 01:05:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A414D63B15A; Tue, 30 Aug 2005 05:05:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id D794E63B158 for ; Tue, 30 Aug 2005 05:05:20 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id CB68434AC0; Tue, 30 Aug 2005 16:46:38 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04945-04; Tue, 30 Aug 2005 16:46:38 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id B632134A62; Tue, 30 Aug 2005 16:46:38 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B155137751; Tue, 30 Aug 2005 16:46:38 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1E9y1D-0003hc-00; Tue, 30 Aug 2005 16:46:43 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: eric_wade_brown@yahoo.com, sommerfeld@sun.com Subject: Re: New draft possibilities Cc: ietf-ssh@NetBSD.org In-Reply-To: <1125337606.453.15.camel@thunk> Message-Id: Date: Tue, 30 Aug 2005 16:46:43 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >On Sat, 2005-08-27 at 12:13, Eric Brown wrote: >> I was just wondering if there has ever been any >> thought put to making a draft of a UDP tunnel like the >> TCP forwarding function. >This has been suggested before several times. nobody has stepped forward to >write a draft. Are you volunteering to write one? Doesn't the existence of OpenVPN (which does exactly this) make this more or less redundant? That might explain the lack of enthusiasm for it, there's already something that does this freely available. (If you're using UDP then you have to provide your own reliability layer, so OpenVPN uses IPsec's UDP-based transport without all of the other IPsec baggage. If you wanted to do this with SSH you'd be more or less reinventing OpenVPN). Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 01:24:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ybb-0005fK-Sj for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 01:24:20 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07780 for ; Tue, 30 Aug 2005 01:24:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5FDAA63B15D; Tue, 30 Aug 2005 05:24:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 3C07563B158 for ; Tue, 30 Aug 2005 05:24:15 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa10994; 30 Aug 2005 1:24 EDT Received: from [192.168.0.101] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7U5O9AY000786 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Aug 2005 01:24:10 -0400 (EDT) Date: Tue, 30 Aug 2005 01:24:08 -0400 From: Jeffrey Hutzelman To: Peter Gutmann , eric_wade_brown@yahoo.com, sommerfeld@sun.com cc: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities Message-ID: <84FA44FDDC5ADB43E9DECBED@bistromath.pc.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01kFVxqvq95h7coOkrw9OhGSfHqNUXier9yp8PxtU=; 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 Content-Transfer-Encoding: 7bit z On Tuesday, August 30, 2005 16:46:43 +1200 Peter Gutmann wrote: > Bill Sommerfeld writes: >> On Sat, 2005-08-27 at 12:13, Eric Brown wrote: >>> I was just wondering if there has ever been any >>> thought put to making a draft of a UDP tunnel like the >>> TCP forwarding function. >> This has been suggested before several times. nobody has stepped >> forward to write a draft. Are you volunteering to write one? > > Doesn't the existence of OpenVPN (which does exactly this) make this more > or less redundant? That might explain the lack of enthusiasm for it, > there's already something that does this freely available. > > (If you're using UDP then you have to provide your own reliability layer, > so OpenVPN uses IPsec's UDP-based transport without all of the other IPsec > baggage. If you wanted to do this with SSH you'd be more or less > reinventing OpenVPN). I think you might be answering the wrong question. The proposal wasn't SSH-over-UDP; it was UDP port forwarding. That does seem like it could be useful. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 01:46:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9yxP-0000s8-Os for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 01:46:56 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08483 for ; Tue, 30 Aug 2005 01:46:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A0FC63B166; Tue, 30 Aug 2005 05:46:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id 909BB63B161 for ; Tue, 30 Aug 2005 05:46:46 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 9215634F48; Tue, 30 Aug 2005 17:46:45 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04389-23; Tue, 30 Aug 2005 17:46:45 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 5B03234F3A; Tue, 30 Aug 2005 17:46:45 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 587BE37752; Tue, 30 Aug 2005 17:46:45 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1E9yxO-0003lz-00; Tue, 30 Aug 2005 17:46:50 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: eric_wade_brown@yahoo.com, jhutz@cmu.edu, pgut001@cs.auckland.ac.nz, sommerfeld@sun.com Subject: Re: New draft possibilities Cc: ietf-ssh@NetBSD.org In-Reply-To: <84FA44FDDC5ADB43E9DECBED@bistromath.pc.cs.cmu.edu> Message-Id: Date: Tue, 30 Aug 2005 17:46:50 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeffrey Hutzelman writes: >I think you might be answering the wrong question. The proposal wasn't SSH- >over-UDP; it was UDP port forwarding. That does seem like it could be useful. Ah, UDP on the inside, not the outside. Right, that could be useful... Peter (who's not volunteering to do it, though :-). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 02:11:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9zLF-0008DI-Jc for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 02:11:30 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20362 for ; Tue, 30 Aug 2005 02:11:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9105C63B16D; Tue, 30 Aug 2005 06:11:20 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.links.org (mail.links.org [217.155.92.109]) by mail.netbsd.org (Postfix) with ESMTP id C3FF463B158 for ; Tue, 30 Aug 2005 06:11:19 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 93B2E33C1A; Tue, 30 Aug 2005 06:41:54 +0100 (BST) Message-ID: <4313FF76.4090809@algroup.co.uk> Date: Tue, 30 Aug 2005 07:40:54 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050405) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: eric_wade_brown@yahoo.com, sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: New draft possibilities References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Bill Sommerfeld writes: > >>On Sat, 2005-08-27 at 12:13, Eric Brown wrote: >> >>>I was just wondering if there has ever been any >>>thought put to making a draft of a UDP tunnel like the >>>TCP forwarding function. >> >>This has been suggested before several times. nobody has stepped forward to >>write a draft. Are you volunteering to write one? > > > Doesn't the existence of OpenVPN (which does exactly this) make this more or > less redundant? That might explain the lack of enthusiasm for it, there's > already something that does this freely available. > > (If you're using UDP then you have to provide your own reliability layer, so > OpenVPN uses IPsec's UDP-based transport without all of the other IPsec > baggage. If you wanted to do this with SSH you'd be more or less reinventing > OpenVPN). And there's DTLS. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 02:44:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9zqx-0007BU-Db for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 02:44:16 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24627 for ; Tue, 30 Aug 2005 02:44:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 06FC063B171; Tue, 30 Aug 2005 06:44:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id 7354563B158 for ; Tue, 30 Aug 2005 06:44:11 +0000 (UTC) Received: from manatee.savecore.net (manatee.savecore.net [209.234.108.155]) by hoth.savecore.net (Postfix) with ESMTP id BA6C42AC40; Mon, 29 Aug 2005 23:42:04 -0700 (PDT) Date: Mon, 29 Aug 2005 23:41:48 -0700 From: Frank Cusack To: Peter Gutmann , eric_wade_brown@yahoo.com, jhutz@cmu.edu, sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On August 30, 2005 5:46:50 PM +1200 Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >> I think you might be answering the wrong question. The proposal wasn't SSH- >> over-UDP; it was UDP port forwarding. That does seem like it could be useful. > > Ah, UDP on the inside, not the outside. Right, that could be useful... A TCP tunnel would change the characteristics of most UDP apps quite significantly and would not be desirable, I'd think. retries within retries ... -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 03:25:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA0Ua-0001ql-C0 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 03:25:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26331 for ; Tue, 30 Aug 2005 03:25:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DC86463B178; Tue, 30 Aug 2005 07:25:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C203E63B158 for ; Tue, 30 Aug 2005 07:25:06 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA19328; Tue, 30 Aug 2005 03:25:06 -0400 (EDT) From: der Mouse Message-Id: <200508300725.DAA19328@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 03:15:47 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> [...] a UDP tunnel like the TCP forwarding function. > Doesn't the existence of OpenVPN (which does exactly this) make this > more or less redundant? No, because depending on what "exactly this" is, OpenVPN *doesn't* do "exactly this". In particular, OpenVPN cannot (normally) be set up by a nonprivileged user to "port-forward" UDP traffic `securely' (FWVO "securely"), even if all the port numbers involved are nonprivileged. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 03:30:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA0ZR-0003D4-Q9 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 03:30:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26521 for ; Tue, 30 Aug 2005 03:30:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 688A963B17D; Tue, 30 Aug 2005 07:30:08 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 2B86963B172 for ; Tue, 30 Aug 2005 07:30:07 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA19354; Tue, 30 Aug 2005 03:30:06 -0400 (EDT) From: der Mouse Message-Id: <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 03:25:12 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > A TCP tunnel would change the characteristics of most UDP apps quite > significantly and would not be desirable, I'd think. Depends on what you're using UDP for. It will change the characteristics of UDP, but whether the change is significant will depend on the application UDP is being put to. For example, I would expect it to work fine for DNS traffic (which is pretty close to the only use I can see for it offhand, though that could just mean I don't do much with UDP). I'd expect the hardest part would be handling replies; many UDP-based protocols expect to send some kind of reply back to a packet's sender, so to be useful any UDP-forwarding-over-ssh would have to pass replies back to the sender. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 09:49:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6U2-0002Vn-Hs for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 09:49:02 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13195 for ; Tue, 30 Aug 2005 09:48:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2AC0163B120; Tue, 30 Aug 2005 13:48:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 84B3263B109 for ; Tue, 30 Aug 2005 13:48:54 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822591 for ietf-ssh@NetBSD.org; Tue, 30 Aug 2005 07:48:53 -0600 Message-ID: <431465B2.4070806@vandyke.com> Date: Tue, 30 Aug 2005 07:57:06 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Changes to SFTP v6: new error messages Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I know we have people implementing a number of the extensions that shipped with the latest draft, and so changes to those are not ok. Do we have people that have shipped other portions of the SFTP v6 draft yet? I would like to add two more error codes, and language that requires implementations to interpret errors that aren't defined by the spec as if they were SFTP_E_GENERAL_FAILURE in order to facilitate adding addition errors in a backwards compatible way. I proposing adding the following text: > Implemenations MUST map unrecognized error codes to > SSH_FX_GENERAL_FAILURE. Future revisions of the > protocol will add additional error codes without > bumping the version number. And the following two error codes: > SSH_FX_OWNER_INVALID 29 > The principle specified can not be assigned > as an owner of a file. > > SSH_FX_GROUP_INVALID 30 > The principle specified can not be assigned > as the primary group of a file. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 09:52:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6Xg-0003om-U7 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 09:52:49 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13395 for ; Tue, 30 Aug 2005 09:52:46 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1B55663B1F3; Tue, 30 Aug 2005 13:52:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 3BDAC63B1DC for ; Tue, 30 Aug 2005 13:52:36 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822596 for ietf-ssh@NetBSD.org; Tue, 30 Aug 2005 07:52:35 -0600 Message-ID: <43146691.4040108@vandyke.com> Date: Tue, 30 Aug 2005 08:00:49 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Changes to SFTP v6: change in acl present flag Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Do we have people already shipping SFTP v6 style attributes? Implementation experience has just taught me that I need both the boolean acl-present and the count field in the ACL. Even when the access control part of the acl is not present, there still may be auditing / system alarm entries present. I propose changing the current text to the following: > If the 'acl-present' flag is not set, it indicates that > the file does not have an ACL, as opposed to having an > empty ACL. An empty ACL grants no access, not having > an ACL grants all access. This is distinct from the > case of SSH_FILEXFER_ATTR_ACL not being present in the > attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, > the client can not deduce whether the server does not > support ACLs, did not check the ACL (because doing > so was expensive), or had some other reason for > omitting the data. > > When the 'acl-prenent' flag is not set, there may still > be system audit or alarm type entries in the list. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 09:57:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6cG-00059Q-EP for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 09:57:32 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13588 for ; Tue, 30 Aug 2005 09:57:30 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4076263B10A; Tue, 30 Aug 2005 13:57:29 +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 7438A63B135 for ; Tue, 30 Aug 2005 13:57:28 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Changes to SFTP v6: new error messages Date: Tue, 30 Aug 2005 09:59:59 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188423@beacon.PSC.process.com> Thread-Topic: Changes to SFTP v6: new error messages Thread-Index: AcWtafHwuvCC4/DsST2Hp0iy8eqsRgAAJQ3A From: "Richard Whalen" To: "Joseph Galbraith" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I count 3 new error codes below - SSH_FX_GENERAL_FAILURE is not listed = in the current draft, did you mean SSH_FX_FAILURE? -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On Behalf Of Joseph Galbraith Sent: Tuesday, August 30, 2005 9:57 AM To: ietf-ssh@NetBSD.org Subject: Changes to SFTP v6: new error messages I know we have people implementing a number of the extensions that shipped with the latest draft, and so changes to those are not ok. Do we have people that have shipped other portions of the SFTP v6 draft yet? I would like to add two more error codes, and language that requires implementations to interpret errors that aren't defined by the spec as if they were SFTP_E_GENERAL_FAILURE in order to facilitate adding addition errors in a backwards compatible way. I proposing adding the following text: > Implemenations MUST map unrecognized error codes to > SSH_FX_GENERAL_FAILURE. Future revisions of the > protocol will add additional error codes without > bumping the version number. And the following two error codes: > SSH_FX_OWNER_INVALID 29 > The principle specified can not be assigned > as an owner of a file. > > SSH_FX_GROUP_INVALID 30 > The principle specified can not be assigned > as the primary group of a file. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:07:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6li-0007a5-Mp for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:07:18 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14256 for ; Tue, 30 Aug 2005 10:07:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AD54F63B210; Tue, 30 Aug 2005 14:07:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 012EB63B201 for ; Tue, 30 Aug 2005 14:07:14 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822671 for ietf-ssh@NetBSD.org; Tue, 30 Aug 2005 08:07:13 -0600 Message-ID: <431469FF.3050500@vandyke.com> Date: Tue, 30 Aug 2005 08:15:27 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: New SFTP extension: copy files on server... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I know I promised we were done adding complexity, but as an non-mandatory extension, I think this could provide a significant performance optimization for some users: byte SSH_FXP_EXTENDED uint32 request-id string "copy" string src-path [UTF-8] string dst-path [UTF-8] UINT cpy-flags cpy-flags would be: SFX_CPY_RECURSIVE Without this flag, src-path most not be a directory SFX_CPY_OVERWRITE This flag requests that if 'dst-path' exists, it be overwritten. Because of the semantics of the copy operation (and limitations on the server) it is not possible to overwrite a directory. SFX_CPY_PRESERVE This flag requests the server to preserve mode, owner, group, and access control lists. What is actually preserved is implementation dependent. If 'dst-path' does not exist, the server uses the exact path specified in 'dst-path' for the destination. If 'dst-path' exists, and is a directory, the server uses the builds the actual 'dst-path' by combining the specified path with the last component of the src-path. If the 'dst-path' derived in this fashion already exists, and is a folder, and the src-path is not a folder, it is an error. If the src-path is a folder, and SFX_CPY_OVERWRITE is specified, the files from the src-path are copied into the target folder, overwriting an files that have the same name. Files already existing in the dst-path that are not in the src-path are not changed in any way. Thoughts? Hate it? Love it, but it needs X? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:10:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6oU-0007vG-MD for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:10:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14513 for ; Tue, 30 Aug 2005 10:10:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 327CC63B1D3; Tue, 30 Aug 2005 14:09:25 +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 51A7C63B135 for ; Tue, 30 Aug 2005 14:09:24 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Changes to SFTP v6: change in acl present flag Date: Tue, 30 Aug 2005 10:11:55 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188424@beacon.PSC.process.com> Thread-Topic: Changes to SFTP v6: change in acl present flag Thread-Index: AcWtanhNdWIDSVvgRXOX7rk7VX61dwAAX1SQ From: "Richard Whalen" To: "Joseph Galbraith" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I have not implemented SFTP v6 style attributes yet, but I don't = understand why audit and alarm ACEs are being considered differently = from access ACEs when setting the acl-present flag. -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On Behalf Of Joseph Galbraith Sent: Tuesday, August 30, 2005 10:01 AM To: ietf-ssh@NetBSD.org Subject: Changes to SFTP v6: change in acl present flag Do we have people already shipping SFTP v6 style attributes? Implementation experience has just taught me that I need both the boolean acl-present and the count field in the ACL. Even when the access control part of the acl is not present, there still may be auditing / system alarm entries present. I propose changing the current text to the following: > If the 'acl-present' flag is not set, it indicates that > the file does not have an ACL, as opposed to having an > empty ACL. An empty ACL grants no access, not having > an ACL grants all access. This is distinct from the > case of SSH_FILEXFER_ATTR_ACL not being present in the > attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, > the client can not deduce whether the server does not > support ACLs, did not check the ACL (because doing > so was expensive), or had some other reason for > omitting the data. >=20 > When the 'acl-prenent' flag is not set, there may still > be system audit or alarm type entries in the list. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:14:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6t2-0000OU-0a for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:14:52 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15028 for ; Tue, 30 Aug 2005 10:14:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1C63763B16D; Tue, 30 Aug 2005 14:14:48 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 65DB063B135 for ; Tue, 30 Aug 2005 14:14:47 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822713; Tue, 30 Aug 2005 08:14:46 -0600 Message-ID: <43146BC4.7070107@vandyke.com> Date: Tue, 30 Aug 2005 08:23:00 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: new error messages References: <3EF96AF20489A34296050FBD5C36ECB9188423@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB9188423@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > I count 3 new error codes below - SSH_FX_GENERAL_FAILURE is not listed in the current draft, did you mean SSH_FX_FAILURE? Yep! Thanks for the good catch. Joseph > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On > Behalf Of Joseph Galbraith > Sent: Tuesday, August 30, 2005 9:57 AM > To: ietf-ssh@NetBSD.org > Subject: Changes to SFTP v6: new error messages > > > I know we have people implementing a number of the extensions > that shipped with the latest draft, and so changes to those > are not ok. > > Do we have people that have shipped other portions of the > SFTP v6 draft yet? > > I would like to add two more error codes, and language that > requires implementations to interpret errors that aren't > defined by the spec as if they were SFTP_E_GENERAL_FAILURE > in order to facilitate adding addition errors in a backwards > compatible way. > > I proposing adding the following text: > >> Implemenations MUST map unrecognized error codes to >> SSH_FX_GENERAL_FAILURE. Future revisions of the >> protocol will add additional error codes without >> bumping the version number. > > And the following two error codes: > > > SSH_FX_OWNER_INVALID 29 > > The principle specified can not be assigned > > as an owner of a file. > > > > SSH_FX_GROUP_INVALID 30 > > The principle specified can not be assigned > > as the primary group of a file. > > > Thanks, > > Joseph > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:21:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6yz-0002kx-Qq for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:21:02 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15682 for ; Tue, 30 Aug 2005 10:20:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7231063B207; Tue, 30 Aug 2005 14:20:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 63BE163B135 for ; Tue, 30 Aug 2005 14:20:56 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822736; Tue, 30 Aug 2005 08:20:55 -0600 Message-ID: <43146D35.7020209@vandyke.com> Date: Tue, 30 Aug 2005 08:29:09 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: change in acl present flag References: <3EF96AF20489A34296050FBD5C36ECB9188424@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB9188424@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > I have not implemented SFTP v6 style attributes yet, but I > don't understand why audit and alarm ACEs are being considered > differently from access ACEs when setting the acl-present > flag. Well, at least under NT, they are maintained in a different list-- normal ACLs are in the discretionary access control list; audit / alarm ACEs are in the system access control list... Leading to the ability to have no Discretionary access control list but still have audit / alarm entries. So... I'm hoping to be able to implement this in a way that can talk w/ other NT based servers correctly... I didn't think VMS did this... it sounds like I was right? Thanks, Joseph > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On > Behalf Of Joseph Galbraith > Sent: Tuesday, August 30, 2005 10:01 AM > To: ietf-ssh@NetBSD.org > Subject: Changes to SFTP v6: change in acl present flag > > > Do we have people already shipping SFTP v6 > style attributes? > > Implementation experience has just taught me that > I need both the boolean acl-present and the count field > in the ACL. > > Even when the access control part of the acl is not > present, there still may be auditing / system alarm > entries present. > > I propose changing the current text to the following: > >> If the 'acl-present' flag is not set, it indicates that >> the file does not have an ACL, as opposed to having an >> empty ACL. An empty ACL grants no access, not having >> an ACL grants all access. This is distinct from the >> case of SSH_FILEXFER_ATTR_ACL not being present in the >> attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, >> the client can not deduce whether the server does not >> support ACLs, did not check the ACL (because doing >> so was expensive), or had some other reason for >> omitting the data. >> >> When the 'acl-prenent' flag is not set, there may still >> be system audit or alarm type entries in the list. > > Thanks, > > Joseph > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:29:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA77R-0004fs-PZ for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:29:45 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16228 for ; Tue, 30 Aug 2005 10:29:42 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 073E863B227; Tue, 30 Aug 2005 14:28:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 97A7E63B124 for ; Tue, 30 Aug 2005 14:28:49 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822769 for ietf-ssh@NetBSD.org; Tue, 30 Aug 2005 08:28:49 -0600 Message-ID: <43146F0E.1070805@vandyke.com> Date: Tue, 30 Aug 2005 08:37:02 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: New SFTP extension: enable privileges on the server... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit In some operating systems (Windows NT, VMS I think, not sure about the big mainframe OSes), a user can have the right to certain privileges, but most explicitly activate the privilege in order to use it. Two such privilege under Windows NT are the Backup privilege and the Restore privilege. In order to make SFTP a more useful protocol, I propose adding the following extension: byte SSH_FXP_EXTENDED uint32 request-id string "enable-privilege" / "disable-privilege" boolean require-all string priv-list[] priv-list strings are either implementation dependent, or from the following list. MS privileges as defined in the PSDK: 'ms-priv-name'@microsoft.ietf.org Standard privileges: BACKUP@ Right to read any file or directory, bypassing read access control checks. RESTORE@ Right to create / write any file or directory, bypassing access control checks. I'm not sure if there are any other privileges that should be standard? If the server doesn't support a given privilege, the user implicitly doesn't have the right to enable it. If 'require-all' flag is specified and any of the privileges could not be enabled, or if none of the privileges could not be enabled, the server MUST disable an privileges that were enabled and send an appropriate error code. (SSH_FX_PERMISSION_DENIED if the user doesn't have the right to enable the requested privileges.) If the 'require-all' flag is not set, and some of the privileges were enabled, the server responds with: byte SSH_FXP_EXTENDED_REPLY uint32 request-id string enabled-privileges[] Because of it's security sensitive nature, implementations SHOULD provide a site specific means of enabling or disabling it. It SHOULD be disabled by default. What do people think? If I need to I can do this one as a @vandyke.com if / when we get ready to support it. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:32:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA79c-00054w-NH for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:32:00 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16325 for ; Tue, 30 Aug 2005 10:31:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 813CE63B1CC; Tue, 30 Aug 2005 14:31:54 +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 5315163B208 for ; Tue, 30 Aug 2005 14:31:53 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Changes to SFTP v6: change in acl present flag Date: Tue, 30 Aug 2005 10:34:24 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188426@beacon.PSC.process.com> Thread-Topic: Changes to SFTP v6: change in acl present flag Thread-Index: AcWtbmW+QT7JEYRDTn6r0h//J+BZzQAAR8lg From: "Richard Whalen" To: "Joseph Galbraith" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable VMS only has a single access control list per file that contains both = discretionary access control entries and audit / alarm entries. The explanation that Windows NT has two ACLs per file helps in = explaining the motive for the change. I can understand how the change = could improve efficiency in a pure Windows NT environment. In a mixed = environment I think that it is a wash. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, August 30, 2005 10:29 AM To: Richard Whalen Cc: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: change in acl present flag Richard Whalen wrote: > I have not implemented SFTP v6 style attributes yet, but I > don't understand why audit and alarm ACEs are being considered > differently from access ACEs when setting the acl-present > flag. Well, at least under NT, they are maintained in a different list-- normal ACLs are in the discretionary access control list; audit / alarm ACEs are in the system access control list... Leading to the ability to have no Discretionary access control list but still have audit / alarm entries. So... I'm hoping to be able to implement this in a way that can talk w/ other NT based servers correctly... I didn't think VMS did this... it sounds like I was right? Thanks, Joseph > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On > Behalf Of Joseph Galbraith > Sent: Tuesday, August 30, 2005 10:01 AM > To: ietf-ssh@NetBSD.org > Subject: Changes to SFTP v6: change in acl present flag >=20 >=20 > Do we have people already shipping SFTP v6 > style attributes? >=20 > Implementation experience has just taught me that > I need both the boolean acl-present and the count field > in the ACL. >=20 > Even when the access control part of the acl is not > present, there still may be auditing / system alarm > entries present. >=20 > I propose changing the current text to the following: >=20 >> If the 'acl-present' flag is not set, it indicates that >> the file does not have an ACL, as opposed to having an >> empty ACL. An empty ACL grants no access, not having >> an ACL grants all access. This is distinct from the >> case of SSH_FILEXFER_ATTR_ACL not being present in the >> attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, >> the client can not deduce whether the server does not >> support ACLs, did not check the ACL (because doing >> so was expensive), or had some other reason for >> omitting the data. >> >> When the 'acl-prenent' flag is not set, there may still >> be system audit or alarm type entries in the list. >=20 > Thanks, >=20 > Joseph >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:44:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7LG-0000HC-My for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:44:02 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16918 for ; Tue, 30 Aug 2005 10:44:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D0A3A63B1DD; Tue, 30 Aug 2005 14:43:59 +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 249AB63B1D1 for ; Tue, 30 Aug 2005 14:43:59 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: New SFTP extension: enable privileges on the server... Date: Tue, 30 Aug 2005 10:46:30 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188427@beacon.PSC.process.com> Thread-Topic: New SFTP extension: enable privileges on the server... Thread-Index: AcWtb6Dr8EdnXIRrQ6K/HJCoIfY5PQAAQU8g From: "Richard Whalen" To: "Joseph Galbraith" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Yes, VMS fits the rational for this extension. I think that this and the copy files extension are interesting = extensions, but I'm also of the feeling that they should be put in an = informational draft because the more that keeps getting added to the = main SFTP draft, the longer it will be before we have sufficient = consensus for it to move forward as an RFC. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:46:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7Nv-0000Y0-34 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:46:47 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17003 for ; Tue, 30 Aug 2005 10:46:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 424D963B288; Tue, 30 Aug 2005 14:46:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 4686063B285 for ; Tue, 30 Aug 2005 14:46:43 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822843; Tue, 30 Aug 2005 08:46:42 -0600 Message-ID: <4314733F.2050108@vandyke.com> Date: Tue, 30 Aug 2005 08:54:55 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: change in acl present flag References: <3EF96AF20489A34296050FBD5C36ECB9188426@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB9188426@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > VMS only has a single access control list per file that > contains both discretionary access control entries > and audit / alarm entries. > > The explanation that Windows NT has two ACLs per file > helps in explaining the motive for the change. I can > understand how the change could improve efficiency in > a pure Windows NT environment. In a mixed environment > I think that it is a wash. Will it interfere with VMS though? Or with inter operating with VMS? For example, would it be unclear what the correct behavior for your server is if a client attempted to set 'acl present' = false + an audit ace? Does VMS have the ability to not have a acl on the file, and does it mean that all access is granted to the file? Thanks, Joseph > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, August 30, 2005 10:29 AM > To: Richard Whalen > Cc: ietf-ssh@NetBSD.org > Subject: Re: Changes to SFTP v6: change in acl present flag > > > Richard Whalen wrote: >> I have not implemented SFTP v6 style attributes yet, but I > > don't understand why audit and alarm ACEs are being considered > > differently from access ACEs when setting the acl-present > > flag. > > Well, at least under NT, they are maintained in a different > list-- normal ACLs are in the discretionary access control > list; audit / alarm ACEs are in the system access control > list... > > Leading to the ability to have no Discretionary access control > list but still have audit / alarm entries. > > So... I'm hoping to be able to implement this in a way > that can talk w/ other NT based servers correctly... > > I didn't think VMS did this... it sounds like I was right? > > Thanks, > > Joseph > >> -----Original Message----- >> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On >> Behalf Of Joseph Galbraith >> Sent: Tuesday, August 30, 2005 10:01 AM >> To: ietf-ssh@NetBSD.org >> Subject: Changes to SFTP v6: change in acl present flag >> >> >> Do we have people already shipping SFTP v6 >> style attributes? >> >> Implementation experience has just taught me that >> I need both the boolean acl-present and the count field >> in the ACL. >> >> Even when the access control part of the acl is not >> present, there still may be auditing / system alarm >> entries present. >> >> I propose changing the current text to the following: >> >>> If the 'acl-present' flag is not set, it indicates that >>> the file does not have an ACL, as opposed to having an >>> empty ACL. An empty ACL grants no access, not having >>> an ACL grants all access. This is distinct from the >>> case of SSH_FILEXFER_ATTR_ACL not being present in the >>> attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, >>> the client can not deduce whether the server does not >>> support ACLs, did not check the ACL (because doing >>> so was expensive), or had some other reason for >>> omitting the data. >>> >>> When the 'acl-prenent' flag is not set, there may still >>> be system audit or alarm type entries in the list. >> Thanks, >> >> Joseph >> > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:50:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7Rx-0001R1-9y for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:50:57 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17136 for ; Tue, 30 Aug 2005 10:50:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E19BB63B275; Tue, 30 Aug 2005 14:50:45 +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 34E0763B23E for ; Tue, 30 Aug 2005 14:50:45 +0000 (UTC) Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7UEoi2B004658; Tue, 30 Aug 2005 07:50:44 -0700 (PDT) Received: from 192.9.61.6 (punchin-darrenm.SFBay.Sun.COM [192.9.61.6]) by jurassic.eng.sun.com (8.13.5.Beta0+Sun/8.13.5.Beta0) with ESMTP id j7UEobfN770421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 30 Aug 2005 07:50:40 -0700 (PDT) Subject: Re: New SFTP extension: enable privileges on the server... From: Darren J Moffat To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org In-Reply-To: <43146F0E.1070805@vandyke.com> References: <43146F0E.1070805@vandyke.com> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1125413411.4264.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Tue, 30 Aug 2005 15:50:13 +0100 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-08-30 at 15:37, Joseph Galbraith wrote: > In some operating systems (Windows NT, VMS I think, not sure > about the big mainframe OSes), a user can have the right to > certain privileges, but most explicitly activate the privilege > in order to use it. (Open)Solaris and Trusted Solaris have privileges and authorisations. Users have authorisations. Processes have privileges. In Solaris a process can manipulate its privileges and privileged processes check authorisations. Lets take a hypothetical example: We have a backup program that only certain users are allowed to use, the backup process uses privileges to read/write files it wouldn't otherwise be able to. That same backup program checks authorisations to ensure that only the correct subset of users can perform restores. > Two such privilege under Windows NT are the Backup privilege > and the Restore privilege. In Solaris processes have privileges - this is the breakup of the all powerful root. A process has a number of different privilege sets: E - Effective Set: What I'm using now. P - Permitted Set: Max I can use. I - Inheritable Set: What I give to children. L - Limit Set: Max children can get. Given that I think your packet needs a place to specify the privilege set as well for this to be useful on Solaris. We could assume the effective set is what you wanted to manipulate since it sounds like that matches your Windows view, but it would be better to allow it to be explicit. > Standard privileges: > BACKUP@ > Right to read any file or directory, bypassing > read access control checks. Sounds like file_dac_read in Solaris. > RESTORE@ > Right to create / write any file or directory, > bypassing access control checks. Sounds like file_dac_write for Solaris. I sounds an interesting proposal. My major question though is what is the expected behaviour if a Windows client connects to a Solaris server and asks for BACKUP@ to be enabled ? Are we supposed to map this to file_dac_read ? What if it is the other way around ? -- Darren J Moffat TZ=Europe/Dublin From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 10:50:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7Rx-0001RG-V5 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:50:58 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17139 for ; Tue, 30 Aug 2005 10:50:55 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CD90263B2C2; Tue, 30 Aug 2005 14:50:50 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 0D73363B25C for ; Tue, 30 Aug 2005 14:50:49 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7822889; Tue, 30 Aug 2005 08:50:49 -0600 Message-ID: <43147437.1000206@vandyke.com> Date: Tue, 30 Aug 2005 08:59:03 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Richard Whalen CC: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: New SFTP extension: enable privileges on the server... References: <3EF96AF20489A34296050FBD5C36ECB9188427@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB9188427@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > Yes, VMS fits the rational for this extension. > > I think that this and the copy files extension are > interesting extensions, but I'm also of the feeling > that they should be put in an informational draft > because the more that keeps getting added to the > main SFTP draft, the longer it will be before we have > sufficient consensus for it to move forward as an RFC. All right... that sounds fine to me. That also means we can defer fleshing out the proposals until someone is ready to implement them. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:00:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7bD-0003b9-I9 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:00:31 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17508 for ; Tue, 30 Aug 2005 11:00:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 600DC63B1F3; Tue, 30 Aug 2005 15:00:24 +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 31FA263B10A for ; Tue, 30 Aug 2005 15:00:23 +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 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Changes to SFTP v6: change in acl present flag Date: Tue, 30 Aug 2005 11:02:54 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB9188428@beacon.PSC.process.com> Thread-Topic: Changes to SFTP v6: change in acl present flag Thread-Index: AcWtcf/jvT21+6wzSuyMOBIjBYsazQAADwGQ From: "Richard Whalen" To: "Joseph Galbraith" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I don't think that it will interfere with VMS, or with inter operating = with VMS. All that it would change is the logic for processing ACEs = would have to consider the value of both the boolean and the count. Files on VMS may or may not have an ACL. All files on VMS still have = the traditional System, Owner, Group, and World discretionary access = fields. These each have bits for Read, Write, Execute (which is a = subset of read, not the Unix Execute), and Delete. Each process has a = default protection mask that is used when a file is created and the = protection is not specified; there is no default ACL value for a = process. Richard -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, August 30, 2005 10:55 AM To: Richard Whalen Cc: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: change in acl present flag Richard Whalen wrote: > VMS only has a single access control list per file that > contains both discretionary access control entries > and audit / alarm entries. >=20 > The explanation that Windows NT has two ACLs per file > helps in explaining the motive for the change. I can > understand how the change could improve efficiency in > a pure Windows NT environment. In a mixed environment > I think that it is a wash. Will it interfere with VMS though? Or with inter operating with VMS? For example, would it be unclear what the correct behavior for your server is if a client attempted to set 'acl present' =3D false + an audit ace? Does VMS have the ability to not have a acl on the file, and does it mean that all access is granted to the file? Thanks, Joseph > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, August 30, 2005 10:29 AM > To: Richard Whalen > Cc: ietf-ssh@NetBSD.org > Subject: Re: Changes to SFTP v6: change in acl present flag >=20 >=20 > Richard Whalen wrote: >> I have not implemented SFTP v6 style attributes yet, but I > > don't understand why audit and alarm ACEs are being considered > > differently from access ACEs when setting the acl-present > > flag. >=20 > Well, at least under NT, they are maintained in a different > list-- normal ACLs are in the discretionary access control > list; audit / alarm ACEs are in the system access control > list... >=20 > Leading to the ability to have no Discretionary access control > list but still have audit / alarm entries. >=20 > So... I'm hoping to be able to implement this in a way > that can talk w/ other NT based servers correctly... >=20 > I didn't think VMS did this... it sounds like I was right? >=20 > Thanks, >=20 > Joseph >=20 >> -----Original Message----- >> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On >> Behalf Of Joseph Galbraith >> Sent: Tuesday, August 30, 2005 10:01 AM >> To: ietf-ssh@NetBSD.org >> Subject: Changes to SFTP v6: change in acl present flag >> >> >> Do we have people already shipping SFTP v6 >> style attributes? >> >> Implementation experience has just taught me that >> I need both the boolean acl-present and the count field >> in the ACL. >> >> Even when the access control part of the acl is not >> present, there still may be auditing / system alarm >> entries present. >> >> I propose changing the current text to the following: >> >>> If the 'acl-present' flag is not set, it indicates that >>> the file does not have an ACL, as opposed to having an >>> empty ACL. An empty ACL grants no access, not having >>> an ACL grants all access. This is distinct from the >>> case of SSH_FILEXFER_ATTR_ACL not being present in the >>> attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, >>> the client can not deduce whether the server does not >>> support ACLs, did not check the ACL (because doing >>> so was expensive), or had some other reason for >>> omitting the data. >>> >>> When the 'acl-prenent' flag is not set, there may still >>> be system audit or alarm type entries in the list. >> Thanks, >> >> Joseph >> >=20 >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:09:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7jy-0006Cn-6M for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:09:34 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18114 for ; Tue, 30 Aug 2005 11:09:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B5A8F63B23E; Tue, 30 Aug 2005 15:09:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id 8988F63B171 for ; Tue, 30 Aug 2005 15:09:25 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E48C1E0049; Tue, 30 Aug 2005 11:08:53 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: [Elwyn Davies] Gen-art review: draft-ietf-secsh-break-04 From: Sam Hartman Date: Tue, 30 Aug 2005 11:08:53 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= In break, was it the intent of the WG for the break length parameter to be optional? --Sam --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Tue, 30 Aug 2005 10:30:57 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by suchdamage.org (Postfix) with ESMTP id E8A3F1383C for ; Tue, 30 Aug 2005 10:30:56 -0400 (EDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP id j7UEUsSl011813 for ; Tue, 30 Aug 2005 10:30:55 -0400 (EDT) Received: from smtp.aaisp.net.uk (B.painless.aaisp.net.uk [81.187.81.52]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id j7UESAuQ015882 for ; Tue, 30 Aug 2005 10:28:10 -0400 (EDT) Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EA75U-0001QY-Ap; Tue, 30 Aug 2005 15:27:44 +0100 Message-ID: <43146D31.8060303@dial.pipex.com> Date: Tue, 30 Aug 2005 15:29:05 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en To: gen-art@ietf.org Cc: Mary Barnes , Sam Hartman , galb-list@vandyke.com, remaker@cisco.com Subject: Gen-art review: draft-ietf-secsh-break-04 X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 Background for those on the CC list, who may be unaware of GenART: GenART is the Area Review Team for the General Area of the IETF. We advise the General Area Director (i.e. the IETF/IESG chair) by providing more in depth reviews than he could do himself of documents that come up for final decision in IESG telechat. I was selected as the GenART member to review this document. Below is my review, which was written specifically with an eye to the GenART process, but since I believe that it will be useful to have these comments more widely distributed, others outside the GenART group are being copied. Document: draft-ietf-secsh-break-04.txt Intended Status: Proposed Standard Shepherding AD: Sam Hartman Review Trigger: IESG Telechat 1/9/05 Review: This document is almost ready for publication as a proposed standard but it has one possible (minor) issue and a couple of editorial nits. Possible issue: [I say 'possible' because I am not an ssh expert but there is an apparent inconsistency with other ssh documents which makes me wonder]. s2: para 4: The text says 'If the BREAK-length parameter is 0 *or not present*, the BREAK SHOULD be interpreted...'. As far as I can see no other ssh message has optional parameters in this way. Although it would obviously be possible to cope with both cases, it seems to be unusual and makes parsing the message more complex than it needs to be, given that this message is going to be a relative rarity. Was this intended? If so I think it would be desirable to add an explicit note closer to the message definition to point out that the parameter is optional. Otherwise just delete 'or not present'. Editorial: s1: para 1: Add a reference to the SSH Connection protocol [5] after 'session channel'. s3: Choose between 'break-length' (as in message format) and 'BREAK-length' (as in para 4). s3: next to last para: (2 places) s/preformed/performed/ --=-=-=-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:18:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7sq-0008OG-Fq for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:18:44 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18443 for ; Tue, 30 Aug 2005 11:18:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 894A663B16D; Tue, 30 Aug 2005 15:18:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 5CDEA63B120 for ; Tue, 30 Aug 2005 15:18:39 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA20675; Tue, 30 Aug 2005 11:18:38 -0400 (EDT) From: der Mouse Message-Id: <200508301518.LAA20675@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 11:12:58 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: new error messages In-Reply-To: <431465B2.4070806@vandyke.com> References: <431465B2.4070806@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I proposing adding the following text: >> Implemenations MUST map unrecognized error codes to >> SSH_FX_GENERAL_FAILURE. Future revisions of the protocol will add >> additional error codes without bumping the version number. I'm not sure I like making it a MUST; for example, this would seem to prohibit using different text when reporting failure to the user ("unrecognized error #29" versus "generic FAILURE", for example). How about Implementations MUST be prepared to receive unexpected error codes and handle them sensibly (such as by treating them as equivalent to SSH_FX_FAILURE). Future protocol revisions will add additional error codes without changing the version number. > And the following two error codes: >> SSH_FX_OWNER_INVALID 29 >> The principle specified can not be assigned >> as an owner of a file. >> >> SSH_FX_GROUP_INVALID 30 >> The principle specified can not be assigned >> as the primary group of a file. They sound reasonable, but need s/principle/principal/ in the text. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:20:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7uV-0000Ki-Bk for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:20:27 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18540 for ; Tue, 30 Aug 2005 11:20:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8B8B163B1CC; Tue, 30 Aug 2005 15:20:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 9187F63B120 for ; Tue, 30 Aug 2005 15:20:23 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7823027; Tue, 30 Aug 2005 09:20:22 -0600 Message-ID: <43147B24.1000508@vandyke.com> Date: Tue, 30 Aug 2005 09:28:36 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: change in acl present flag References: <3EF96AF20489A34296050FBD5C36ECB9188428@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB9188428@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > Files on VMS may or may not have an ACL. All files on VMS still > have the traditional System, Owner, Group, and World > discretionary access fields. These each have bits for Read, > Write, Execute (which is a subset of read, not the Unix Execute), > and Delete. Each process has a default protection mask that is > used when a file is created and the protection is not > specified; there is no default ACL value for a process. I'd forgotten about the traditional access mask. Would it be useful to allocate some additional bits in the permissions mask to represent the extra data in this field? Also, does an empty (as opposed to absent) ACL deny all access? Thanks, Joseph > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, August 30, 2005 10:55 AM > To: Richard Whalen > Cc: ietf-ssh@NetBSD.org > Subject: Re: Changes to SFTP v6: change in acl present flag > > > Richard Whalen wrote: >> VMS only has a single access control list per file that > > contains both discretionary access control entries > > and audit / alarm entries. >> The explanation that Windows NT has two ACLs per file > > helps in explaining the motive for the change. I can > > understand how the change could improve efficiency in > > a pure Windows NT environment. In a mixed environment > > I think that it is a wash. > > Will it interfere with VMS though? Or with inter operating > with VMS? > > For example, would it be unclear what the correct behavior > for your server is if a client attempted to set > 'acl present' = false + an audit ace? > > Does VMS have the ability to not have a acl on the file, > and does it mean that all access is granted to the file? > > Thanks, > > Joseph > >> -----Original Message----- >> From: Joseph Galbraith [mailto:galb-list@vandyke.com] >> Sent: Tuesday, August 30, 2005 10:29 AM >> To: Richard Whalen >> Cc: ietf-ssh@NetBSD.org >> Subject: Re: Changes to SFTP v6: change in acl present flag >> >> >> Richard Whalen wrote: >>> I have not implemented SFTP v6 style attributes yet, but I >> > don't understand why audit and alarm ACEs are being considered >> > differently from access ACEs when setting the acl-present >> > flag. >> >> Well, at least under NT, they are maintained in a different >> list-- normal ACLs are in the discretionary access control >> list; audit / alarm ACEs are in the system access control >> list... >> >> Leading to the ability to have no Discretionary access control >> list but still have audit / alarm entries. >> >> So... I'm hoping to be able to implement this in a way >> that can talk w/ other NT based servers correctly... >> >> I didn't think VMS did this... it sounds like I was right? >> >> Thanks, >> >> Joseph >> >>> -----Original Message----- >>> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On >>> Behalf Of Joseph Galbraith >>> Sent: Tuesday, August 30, 2005 10:01 AM >>> To: ietf-ssh@NetBSD.org >>> Subject: Changes to SFTP v6: change in acl present flag >>> >>> >>> Do we have people already shipping SFTP v6 >>> style attributes? >>> >>> Implementation experience has just taught me that >>> I need both the boolean acl-present and the count field >>> in the ACL. >>> >>> Even when the access control part of the acl is not >>> present, there still may be auditing / system alarm >>> entries present. >>> >>> I propose changing the current text to the following: >>> >>>> If the 'acl-present' flag is not set, it indicates that >>>> the file does not have an ACL, as opposed to having an >>>> empty ACL. An empty ACL grants no access, not having >>>> an ACL grants all access. This is distinct from the >>>> case of SSH_FILEXFER_ATTR_ACL not being present in the >>>> attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, >>>> the client can not deduce whether the server does not >>>> support ACLs, did not check the ACL (because doing >>>> so was expensive), or had some other reason for >>>> omitting the data. >>>> >>>> When the 'acl-prenent' flag is not set, there may still >>>> be system audit or alarm type entries in the list. >>> Thanks, >>> >>> Joseph >>> >> > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:23:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7xB-0000mK-R1 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:23:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18644 for ; Tue, 30 Aug 2005 11:23:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F3B9F63B288; Tue, 30 Aug 2005 15:21:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 16D6563B1DD for ; Tue, 30 Aug 2005 15:21:55 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7823043; Tue, 30 Aug 2005 09:21:53 -0600 Message-ID: <43147B7F.6000100@vandyke.com> Date: Tue, 30 Aug 2005 09:30:07 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Sam Hartman CC: ietf-ssh@NetBSD.org Subject: Re: [Elwyn Davies] Gen-art review: draft-ietf-secsh-break-04 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sam Hartman wrote: > In break, was it the intent of the WG for the break length parameter > to be optional? I don't recall... it probably just happened. I, for one, would be happy to remove the offending phrase. Does anyone recall differently? Thanks, Joseph > ------------------------------------------------------------------------ > > Subject: > Gen-art review: draft-ietf-secsh-break-04 > From: > Elwyn Davies > Date: > Tue, 30 Aug 2005 15:29:05 +0100 > To: > gen-art@ietf.org > > To: > gen-art@ietf.org > CC: > Mary Barnes , Sam Hartman > , galb-list@vandyke.com, remaker@cisco.com > > > Background for those on the CC list, who may be unaware of GenART: > GenART is the Area Review Team for the General Area of the IETF. We > advise the General Area Director (i.e. the IETF/IESG chair) by providing > more in depth reviews than he could do himself of documents that come up > for final decision in IESG telechat. I was selected as the GenART > member to review this document. Below is my review, which was written > specifically with an eye to the GenART process, but since I believe that > it will be useful to have these comments more widely distributed, others > outside the GenART group are being copied. > > Document: draft-ietf-secsh-break-04.txt > Intended Status: Proposed Standard > Shepherding AD: Sam Hartman > Review Trigger: IESG Telechat 1/9/05 > > Review: > This document is almost ready for publication as a proposed standard but > it has one possible (minor) issue and a couple of editorial nits. > > Possible issue: > [I say 'possible' because I am not an ssh expert but there is an > apparent inconsistency with other ssh documents which makes me wonder]. > s2: para 4: The text says 'If the BREAK-length parameter is 0 *or not > present*, the BREAK SHOULD be interpreted...'. As far as I can see no > other ssh message has optional parameters in this way. Although it would > obviously be possible to cope with both cases, it seems to be unusual > and makes parsing the message more complex than it needs to be, given > that this message is going to be a relative rarity. Was this intended? > If so I think it would be desirable to add an explicit note closer to > the message definition to point out that the parameter is optional. > Otherwise just delete 'or not present'. > > Editorial: > s1: para 1: Add a reference to the SSH Connection protocol [5] after > 'session channel'. > s3: Choose between 'break-length' (as in message format) and > 'BREAK-length' (as in para 4). > s3: next to last para: (2 places) s/preformed/performed/ > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:27:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA81c-0001lJ-8r for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:27:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18771 for ; Tue, 30 Aug 2005 11:27:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8741363B2F4; Tue, 30 Aug 2005 15:27:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6D59D63B120 for ; Tue, 30 Aug 2005 15:27:39 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA20716; Tue, 30 Aug 2005 11:27:38 -0400 (EDT) From: der Mouse Message-Id: <200508301527.LAA20716@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 11:19:02 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New SFTP extension: copy files on server... In-Reply-To: <431469FF.3050500@vandyke.com> References: <431469FF.3050500@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > byte SSH_FXP_EXTENDED > uint32 request-id > string "copy" > [...] > Thoughts? Hate it? Love it, but it needs X? I'm with Richard Whalen: fine, but not in the core draft. In fact, I'm not convinced _any_ SSH_FXP_EXTENDED packets belong in the core draft (yes, I know there are a handful of them there now). That aside, the description uses both "folder" and "directory", apparently referring to the same thing; I think the terminology should be normalized to the same as the rest of the sftp stuff. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:33:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA86j-0002pN-B4 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:33:05 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18957 for ; Tue, 30 Aug 2005 11:33:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BF65163B38B; Tue, 30 Aug 2005 15:32:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 0972963B2ED for ; Tue, 30 Aug 2005 15:32:06 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7823083; Tue, 30 Aug 2005 09:32:05 -0600 Message-ID: <43147DE3.4030906@vandyke.com> Date: Tue, 30 Aug 2005 09:40:19 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: new error messages References: <431465B2.4070806@vandyke.com> <200508301518.LAA20675@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200508301518.LAA20675@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: >> I proposing adding the following text: > >>> Implemenations MUST map unrecognized error codes to >>> SSH_FX_GENERAL_FAILURE. Future revisions of the protocol will add >>> additional error codes without bumping the version number. > > I'm not sure I like making it a MUST; for example, this would seem to > prohibit using different text when reporting failure to the user > ("unrecognized error #29" versus "generic FAILURE", for example). > > How about > Implementations MUST be prepared to receive unexpected error > codes and handle them sensibly (such as by treating them as > equivalent to SSH_FX_FAILURE). Future protocol revisions will > add additional error codes without changing the version number. This works for me. >> And the following two error codes: > >>> SSH_FX_OWNER_INVALID 29 >>> The principle specified can not be assigned >>> as an owner of a file. >>> >>> SSH_FX_GROUP_INVALID 30 >>> The principle specified can not be assigned >>> as the primary group of a file. > > They sound reasonable, but need s/principle/principal/ in the text. Thanks as always for the spelling. (In case you hadn't noticed, I have a problem with spelling.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:36:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA89b-0003BK-5K for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:36:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19081 for ; Tue, 30 Aug 2005 11:36:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3B1AA63B2ED; Tue, 30 Aug 2005 15:36:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id F259B63B2CF for ; Tue, 30 Aug 2005 15:35:58 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA20821; Tue, 30 Aug 2005 11:35:58 -0400 (EDT) From: der Mouse Message-Id: <200508301535.LAA20821@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 11:31:46 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [Elwyn Davies] Gen-art review: draft-ietf-secsh-break-04 In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > In break, was it the intent of the WG for the break length parameter > to be optional? > The text says 'If the BREAK-length parameter is 0 *or not present*, The "or not present" is absent in break-03 and break-01. The break-length parameter is present in all three versions (-01, -03, -04). I see no reason for the language implying that it's optional, especially since it's not described as optional in the packet layout early in section 3. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:41:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8Ek-0004em-HY for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:41:23 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19391 for ; Tue, 30 Aug 2005 11:41:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 593BD63B2CF; Tue, 30 Aug 2005 15:41:18 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 3AD9D63B120 for ; Tue, 30 Aug 2005 15:41:17 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa17752; 30 Aug 2005 11:40 EDT Received: from [192.168.0.101] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7UFdv4q003587 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Aug 2005 11:39:58 -0400 (EDT) Date: Tue, 30 Aug 2005 11:39:56 -0400 From: Jeffrey Hutzelman To: Frank Cusack , Peter Gutmann , eric_wade_brown@yahoo.com, sommerfeld@sun.com cc: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities Message-ID: <70C83EA2EA678B3137FFA0B2@bistromath.pc.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:011g82bEB3q+AiWq7tCY1m222BbZddQ69DhGTRDI8=; 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 Content-Transfer-Encoding: 7bit On Monday, August 29, 2005 23:41:48 -0700 Frank Cusack wrote: > On August 30, 2005 5:46:50 PM +1200 Peter Gutmann > wrote: >> Jeffrey Hutzelman writes: >> >>> I think you might be answering the wrong question. The proposal wasn't >>> SSH- over-UDP; it was UDP port forwarding. That does seem like it could >>> be useful. >> >> Ah, UDP on the inside, not the outside. Right, that could be useful... > > A TCP tunnel would change the characteristics of most UDP apps quite > significantly and would not be desirable, I'd think. > > retries within retries ... Perhaps, but especially when the network is fairly reliable, it would be better than an app you can't use at all because you have no way to get the packets from here to there. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 11:46:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8JE-0006ji-O9 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:46:00 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19601 for ; Tue, 30 Aug 2005 11:45:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 24C8063B2D5; Tue, 30 Aug 2005 15:45:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 6181163B120 for ; Tue, 30 Aug 2005 15:45:57 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EA8JA-00006k-00 for ietf-ssh@netbsd.org; Tue, 30 Aug 2005 16:45:56 +0100 Date: Tue, 30 Aug 2005 16:45:56 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: [Elwyn Davies] Gen-art review: draft-ietf-secsh-break-04 Message-ID: <20050830154556.GA29543@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list > s2: para 4: The text says 'If the BREAK-length parameter is 0 *or not > present*, the BREAK SHOULD be interpreted...'. As far as I can see no > other ssh message has optional parameters in this way. Although it would To save anyone else grovelling round: I wondered if it was a backwards compatibility measure. However, the "break-length" parameter has been present in every published draft from "draft-ietf-secsh-break-00" (according to tools.ietf.org), and the "or not present" language only appeared in the latest draft (-04). That language doesn't appear to have come from any of the suggested changes from the WG that fed into -04 (e.g., from Ben Harris or der Mouse); it doesn't appear to have been proposed before the publication of -04. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 12:02:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8Z8-0001vp-Lw for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 12:02:26 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20441 for ; Tue, 30 Aug 2005 12:02:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3582D63B18D; Tue, 30 Aug 2005 16:02:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8429463B120 for ; Tue, 30 Aug 2005 16:02:21 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7823232; Tue, 30 Aug 2005 10:02:20 -0600 Message-ID: <431484FA.6050703@vandyke.com> Date: Tue, 30 Aug 2005 10:10:34 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: New SFTP extension: copy files on server... References: <431469FF.3050500@vandyke.com> <200508301527.LAA20716@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200508301527.LAA20716@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: >> byte SSH_FXP_EXTENDED >> uint32 request-id >> string "copy" >> [...] > >> Thoughts? Hate it? Love it, but it needs X? > > I'm with Richard Whalen: fine, but not in the core draft. > > In fact, I'm not convinced _any_ SSH_FXP_EXTENDED packets belong in the > core draft (yes, I know there are a handful of them there now). I suppose I could be convinced to move some of them-- like the hash stuff would be a good candidate. Some of the others though, I do think belong there. version-select and space-available at least belong in the core draft. I could go either way about 'home-directory' > That aside, the description uses both "folder" and "directory", > apparently referring to the same thing; I think the terminology should > be normalized to the same as the rest of the sftp stuff. That is a good point... I'll check the entire draft and normalize to 'directory.' I despise that fact that I've become so corrupt I all them folders :-) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 12:35:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA95K-0002TM-Vv for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 12:35:43 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22310 for ; Tue, 30 Aug 2005 12:35:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C5E5863B331; Tue, 30 Aug 2005 16:35:39 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id A411963B120 for ; Tue, 30 Aug 2005 16:35:38 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA21399; Tue, 30 Aug 2005 12:35:37 -0400 (EDT) From: der Mouse Message-Id: <200508301635.MAA21399@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 12:27:21 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New SFTP extension: copy files on server... In-Reply-To: <431484FA.6050703@vandyke.com> References: <431469FF.3050500@vandyke.com> <200508301527.LAA20716@Sparkle.Rodents.Montreal.QC.CA> <431484FA.6050703@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> In fact, I'm not convinced _any_ SSH_FXP_EXTENDED packets belong in >> the core draft (yes, I know there are a handful of them there now). > I suppose I could be convinced to move some of them-- like the hash > stuff would be a good candidate. Some of the others though, I do > think belong there. > version-select and space-available at least belong in the core draft. version-select, hmm, I think I agree. The others, I think I'm readier to push them out than you are, but since I don't feel strongly enough about it to make a fuss over any of them, it doesn't really matter. :) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 13:29:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA9vZ-0002k8-PI for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 13:29:42 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25329 for ; Tue, 30 Aug 2005 13:29:37 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B631463B34E; Tue, 30 Aug 2005 17:29:27 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id B38E863B343 for ; Tue, 30 Aug 2005 17:29:26 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa16313; 30 Aug 2005 13:28 EDT Date: Tue, 30 Aug 2005 13:28:48 -0400 From: Jeffrey Hutzelman To: Darren J Moffat , Joseph Galbraith cc: ietf-ssh@NetBSD.org Subject: Re: New SFTP extension: enable privileges on the server... Message-ID: <066E96D7D4C844F441FAEBEB@sirius.fac.cs.cmu.edu> In-Reply-To: <1125413411.4264.30.camel@localhost> References: <43146F0E.1070805@vandyke.com> <1125413411.4264.30.camel@localhost> Originator-Info: login-token=Mulberry:017OterlZT0yI4NtYvH2mOHYNdldlzH9dZYIwTIms=; 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 Content-Transfer-Encoding: 7bit On Tuesday, August 30, 2005 03:50:13 PM +0100 Darren J Moffat wrote: > In Solaris processes have privileges - this is the breakup > of the all powerful root. A process has a number of different > privilege sets: > E - Effective Set: What I'm using now. > P - Permitted Set: Max I can use. > I - Inheritable Set: What I give to children. > L - Limit Set: Max children can get. > > Given that I think your packet needs a place to specify > the privilege set as well for this to be useful on Solaris. We > could assume the effective set is what you wanted to manipulate > since it sounds like that matches your Windows view, but it would > be better to allow it to be explicit. I don't think so. In the context of sftp, the only interesting set of privileges are those actually used to perform operations on behalf of the user. Exactly which set is relevant is going to vary depending on the operation in question and how it is implemented (for example, the server might decide to do some operations in a subprocess). The client has no business knowing whether the sftp server has children or what privileges they might have. Similarly, just because the client says "enable this privilege" doesn't mean the entire sftp server needs to run with that privilege all the time. It would be entirely reasonable for an implementation to enable them only when accessing files on the user's behalf. I would suggest adding an operation to fetch the current set of privileges and/or the set of all permitted privileges. The latter would have to be computed by the server based on what privileges are actually permitted to it, what it needs to perform various operations, and local policy. For example, an sftp server might run with privileges which it is not willing to make available to the user. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 14:49:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABAL-00033Q-7z for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 14:49:01 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00089 for ; Tue, 30 Aug 2005 14:48:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8562563B33C; Tue, 30 Aug 2005 18:48:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id DBE8F63B219 for ; Tue, 30 Aug 2005 18:48:55 +0000 (UTC) Received: from maguro.savecore.net (maguro.savecore.net [209.234.108.152]) by hoth.savecore.net (Postfix) with ESMTP id 7C4122AC40; Tue, 30 Aug 2005 11:47:52 -0700 (PDT) Date: Tue, 30 Aug 2005 11:47:51 -0700 From: Frank Cusack To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: New draft possibilities Message-ID: <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> In-Reply-To: <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> References: <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On August 30, 2005 3:25:12 AM -0400 der Mouse wrote: >> A TCP tunnel would change the characteristics of most UDP apps quite >> significantly and would not be desirable, I'd think. > > Depends on what you're using UDP for. It will change the > characteristics of UDP, but whether the change is significant will > depend on the application UDP is being put to. > > For example, I would expect it to work fine for DNS traffic (which is > pretty close to the only use I can see for it offhand, though that > could just mean I don't do much with UDP). But what happens when DNS times out and sends a retry, while TCP has also queued it's own retry? You end up drastically increasing the amount of network traffic. I fail to see how that's a Good Thing. So I'm not sure what you mean by "works fine". What happened or what were the general thoughts on this when X.25 was prevalent? TCP over X.25 is even more interesting than UDP over X.25. Or were IP protocoles not really used over X.25? -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 16:02:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACJH-0000Gg-Bl for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 16:02:19 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07041 for ; Tue, 30 Aug 2005 16:02:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7A84A63B386; Tue, 30 Aug 2005 20:02:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id B3D0C63B384 for ; Tue, 30 Aug 2005 20:02:05 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1EACIx-0006Cb-00; Tue, 30 Aug 2005 21:01:59 +0100 From: Ben Harris To: fcusack@fcusack.com, ietf-ssh@NetBSD.org Subject: Re: New draft possibilities In-Reply-To: <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> References: <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> Organization: Linux Unlimited Message-Id: Date: Tue, 30 Aug 2005 21:01:59 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> you write: >On August 30, 2005 3:25:12 AM -0400 der Mouse wrote: >>> A TCP tunnel would change the characteristics of most UDP apps quite >>> significantly and would not be desirable, I'd think. >> >> Depends on what you're using UDP for. It will change the >> characteristics of UDP, but whether the change is significant will >> depend on the application UDP is being put to. >> >> For example, I would expect it to work fine for DNS traffic (which is >> pretty close to the only use I can see for it offhand, though that >> could just mean I don't do much with UDP). > >But what happens when DNS times out and sends a retry, while TCP has >also queued it's own retry? You end up drastically increasing the >amount of network traffic. Not necessarily. A reasonable implementation of UDP-over-SSH would notice the TCP congestion (in the Unix world, by write() on the TCP socket returning EWOULDBLOCK) and drop incoming UDP until it cleared. I'm not an expert in congestion control, though, and I think one would need to be consulted to determine the actual scope of the problem. >Or were IP protocoles not really used over X.25? They certainly were. When I arrived at University in 1994, we had a 2 Mbit X.25 connection over which we ran IP. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 17:48:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADyV-0007zZ-M9 for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:48:59 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11337 for ; Tue, 30 Aug 2005 17:48:56 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A86C363B373; Tue, 30 Aug 2005 21:48:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id 1BCA063B369 for ; Tue, 30 Aug 2005 21:48:54 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DD1CEE0049; Tue, 30 Aug 2005 17:48:18 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [Elwyn Davies] Gen-art review: draft-ietf-secsh-break-04 References: <20050830154556.GA29543@chiark.greenend.org.uk> From: Sam Hartman Date: Tue, 30 Aug 2005 17:48:18 -0400 In-Reply-To: <20050830154556.GA29543@chiark.greenend.org.uk> (Jacob Nevins's message of "Tue, 30 Aug 2005 16:45:56 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Jacob" == Jacob Nevins writes: Jacob> That language doesn't appear to have come from any of the Jacob> suggested changes from the WG that fed into -04 (e.g., from Jacob> Ben Harris or der Mouse); it doesn't appear to have been Jacob> proposed before the publication of -04. Not a response to any of my comments either. OK, unless someone screams by noon ET tomorrow, it's gone. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 17:53:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAE34-0000pQ-GB for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:53:42 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11562 for ; Tue, 30 Aug 2005 17:53:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2E13563B369; Tue, 30 Aug 2005 21:53:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 84EE663B359 for ; Tue, 30 Aug 2005 21:53:38 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7824423; Tue, 30 Aug 2005 15:53:37 -0600 Message-ID: <4314D74F.80205@vandyke.com> Date: Tue, 30 Aug 2005 16:01:51 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Sam Hartman CC: ietf-ssh@NetBSD.org Subject: Re: [Elwyn Davies] Gen-art review: draft-ietf-secsh-break-04 References: <20050830154556.GA29543@chiark.greenend.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sam Hartman wrote: >>>>>> "Jacob" == Jacob Nevins writes: > > Jacob> That language doesn't appear to have come from any of the > Jacob> suggested changes from the WG that fed into -04 (e.g., from > Jacob> Ben Harris or der Mouse); it doesn't appear to have been > Jacob> proposed before the publication of -04. > > > Not a response to any of my comments either. > > OK, unless someone screams by noon ET tomorrow, it's gone. I believe the intent was that the bits MUST be present in the packet. So ax away. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 18:35:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEhS-0003nI-Fi for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:35:26 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14175 for ; Tue, 30 Aug 2005 18:35:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9233663B394; Tue, 30 Aug 2005 22:35:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id E9F9263B393 for ; Tue, 30 Aug 2005 22:35:21 +0000 (UTC) Received: from maguro.savecore.net (maguro.savecore.net [209.234.108.152]) by hoth.savecore.net (Postfix) with ESMTP id BFDA12AC40; Tue, 30 Aug 2005 15:34:30 -0700 (PDT) Date: Tue, 30 Aug 2005 15:34:30 -0700 From: Frank Cusack To: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: New draft possibilities Message-ID: <7FA96F66EAB99DBC6A1D0CAC@maguro.savecore.net> In-Reply-To: References: <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On August 30, 2005 9:01:59 PM +0100 Ben Harris wrote: > In article <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> you write: >> On August 30, 2005 3:25:12 AM -0400 der Mouse wrote: >>>> A TCP tunnel would change the characteristics of most UDP apps quite >>>> significantly and would not be desirable, I'd think. >>> >>> Depends on what you're using UDP for. It will change the >>> characteristics of UDP, but whether the change is significant will >>> depend on the application UDP is being put to. >>> >>> For example, I would expect it to work fine for DNS traffic (which is >>> pretty close to the only use I can see for it offhand, though that >>> could just mean I don't do much with UDP). >> >> But what happens when DNS times out and sends a retry, while TCP has >> also queued it's own retry? You end up drastically increasing the >> amount of network traffic. > > Not necessarily. A reasonable implementation of UDP-over-SSH would notice > the TCP congestion (in the Unix world, by write() on the TCP socket > returning EWOULDBLOCK) ... Only after the receiver's window goes to 0, and even then only if no packets whatsoever get through. In congested conditions where packets make it after a few retrans, you'll never get this error. You are also assuming something (a lot) about a specific implementation. Nothing requires a TCP stack to notify the application like this. -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 30 23:36:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAJP5-0007mQ-IM for secsh-archive@megatron.ietf.org; Tue, 30 Aug 2005 23:36:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27775 for ; Tue, 30 Aug 2005 23:36:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F12F763B3D3; Wed, 31 Aug 2005 03:36:42 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id BBB5563B110 for ; Wed, 31 Aug 2005 03:36:41 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA25455; Tue, 30 Aug 2005 23:36:40 -0400 (EDT) From: der Mouse Message-Id: <200508310336.XAA25455@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 30 Aug 2005 23:25:21 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New draft possibilities In-Reply-To: References: <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> <200508300730.DAA19354@Sparkle.Rodents.Montreal.QC.CA> <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>> [UDP-over-ssh] >>> For example, I would expect it to work fine for DNS traffic [...] >> But what happens when DNS times out and sends a retry, while TCP has >> also queued it's own retry? > A reasonable implementation of UDP-over-SSH would notice the TCP > congestion (in the Unix world, by write() on the TCP socket returning > EWOULDBLOCK) and drop incoming UDP until it cleared. If that's your idea of TCP congestion pushed back to userland, you need to get your hands dirty with code more[%]. :-) Most kernels buffer some 10-20 K of data before that happens, and that can hold a lot more than a few DNS retries. Yes, eventually buffers fill up, but you need either crippling underlying congestion or a comparative lot of upper-layer traffic to push it clear back to userland. [%] Yes, I know you _do_ get your hands dirty with code. That's why the smiley. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 09:26:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASbt-0003nN-V6 for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 09:26:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20320 for ; Wed, 31 Aug 2005 09:26:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AD0B363B34C; Wed, 31 Aug 2005 13:26:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av-tac-sj.cisco.com (firestar.cisco.com [171.68.227.75]) by mail.netbsd.org (Postfix) with ESMTP id 9DE5263B154 for ; Wed, 31 Aug 2005 13:26:28 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost [127.0.0.1]) by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7VDLSV13718; Wed, 31 Aug 2005 06:21:28 -0700 (PDT) Received: from [10.21.104.12] (sjc-vpnasa1-12.cisco.com [10.21.104.12]) by fire.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7VDLPn06982; Wed, 31 Aug 2005 06:21:25 -0700 (PDT) Message-ID: <4315AED4.7040104@cisco.com> Date: Wed, 31 Aug 2005 06:21:24 -0700 From: Phillip Remaker User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: IESG , Elwyn Davies , galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: DISCUSS: draft-ietf-secsh-break-04 References: <43146D31.8060303@dial.pipex.com> <4315620D.1040206@zurich.ibm.com> In-Reply-To: <4315620D.1040206@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Good point. I'm ambivalent, but I will copy ietf-ssh to see what the opinion of the people who have already developed the protoype code think. I would be OK with the deletion of not present, and assume that all requests must have a break length set with 0 being the default (default break length of server) But I would like to hear opinions. Brian E Carpenter wrote: > This is a very minor point but it needs clearing up. > > From review by Elwyn Davies: > > Possible issue: > [I say 'possible' because I am not an ssh expert but there is an > apparent inconsistency with other ssh documents which makes me wonder]. > s2: para 4: The text says 'If the BREAK-length parameter is 0 *or not > present*, the BREAK SHOULD be interpreted...'. As far as I can see no > other ssh message has optional parameters in this way. Although it > would obviously be possible to cope with both cases, it seems to be > unusual and makes parsing the message more complex than it needs to > be, given that this message is going to be a relative rarity. Was this > intended? If so I think it would be desirable to add an explicit note > closer to the message definition to point out that the parameter is > optional. Otherwise just delete 'or not present'. > > BC: As I read the spec, the channel request always includes > uint32 break-length in milliseconds > so the case where the break-length parameter is absent simply doesn't > exist. If that's correct, indeed just delete 'or not present'. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 09:45:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASuE-0001Gr-LE for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 09:45:34 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20994 for ; Wed, 31 Aug 2005 09:45:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A6A1E63B4A2; Wed, 31 Aug 2005 13:45:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 0776A63B154 for ; Wed, 31 Aug 2005 13:45:31 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1EASu9-0006aT-00; Wed, 31 Aug 2005 14:45:29 +0100 From: Ben Harris To: remaker@cisco.com, ietf-ssh@NetBSD.org Subject: Re: DISCUSS: draft-ietf-secsh-break-04 In-Reply-To: <4315AED4.7040104@cisco.com> References: <43146D31.8060303@dial.pipex.com> <4315620D.1040206@zurich.ibm.com> <4315620D.1040206@zurich.ibm.com> <4315AED4.7040104@cisco.com> Organization: Linux Unlimited Message-Id: Date: Wed, 31 Aug 2005 14:45:29 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <4315AED4.7040104@cisco.com> you write: >Good point. I'm ambivalent, but I will copy ietf-ssh to see what the >opinion of the people who have already developed the protoype code think. FWIW, PuTTY has always included the field, and set it to 0. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 11:24:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUSJ-0004Y8-Ar for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 11:24:51 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26559 for ; Wed, 31 Aug 2005 11:24:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CD89063B4CF; Wed, 31 Aug 2005 15:24:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id CDA6763B4CC for ; Wed, 31 Aug 2005 15:24:36 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7826267; Wed, 31 Aug 2005 09:24:35 -0600 Message-ID: <4315CDA2.2030504@vandyke.com> Date: Wed, 31 Aug 2005 09:32:50 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Joseph Galbraith CC: ietf-ssh@NetBSD.org Subject: Re: Changes to SFTP v6: change in acl present flag References: <43146691.4040108@vandyke.com> In-Reply-To: <43146691.4040108@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Okay, I have a new plan-- people should like this. I haven't heard anyone that has implemented this yet, so I'm going to change w/o bumping version number. + Remove the acl present flag. The meaning of an absent acl (and an empty acl) is different enough so that I don't want to deal with it. + For NT, I'll use a acl-info@vandyke.com extension to allow me to communicate the extra info, which should only be needed rarely. Speak now if you have objections to this plan. Thanks, Joseph Joseph Galbraith wrote: > Do we have people already shipping SFTP v6 > style attributes? > > Implementation experience has just taught me that > I need both the boolean acl-present and the count field > in the ACL. > > Even when the access control part of the acl is not > present, there still may be auditing / system alarm > entries present. > > I propose changing the current text to the following: > >> If the 'acl-present' flag is not set, it indicates that >> the file does not have an ACL, as opposed to having an >> empty ACL. An empty ACL grants no access, not having >> an ACL grants all access. This is distinct from the >> case of SSH_FILEXFER_ATTR_ACL not being present in the >> attrib flags. If SSH_FILEXFER_ATTR_ACL is not present, >> the client can not deduce whether the server does not >> support ACLs, did not check the ACL (because doing >> so was expensive), or had some other reason for >> omitting the data. >> >> When the 'acl-prenent' flag is not set, there may still >> be system audit or alarm type entries in the list. > > Thanks, > > Joseph > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 13:00:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAVx1-0007mM-GH for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 13:00:40 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00621 for ; Wed, 31 Aug 2005 13:00:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7232F63B4E1; Wed, 31 Aug 2005 17:00:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from pigeon.alphaweb.net (69-12-155-130.dsl.static.sonic.net [69.12.155.130]) by mail.netbsd.org (Postfix) with ESMTP id C4E8263B4DA for ; Wed, 31 Aug 2005 17:00:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lighthammer) by pigeon.alphaweb.net with smtp (Exim 4.10) id 1EAVJB-00021u-00 for ietf-ssh@netbsd.org; Wed, 31 Aug 2005 09:19:29 -0700 Message-ID: <015301c5ae4d$7cb18250$6c051fac@lighthammer> Reply-To: "Sara Golemon" From: "Sara Golemon" To: Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) Date: Wed, 31 Aug 2005 10:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > I was just wondering if there has ever been any > thought put to making a draft of a UDP tunnel like the > TCP forwarding function. > I was tossing this idea along with unix domain sockets/windows named pipes and thought it might make more sense to define a generic "socket tunnel" session or subsystem. Something like: byte SSH_MSG_CHANNEL_OPEN string "direct-socket" string socket type name (e.g. "udp","unix","named-pipe") uint32 sender channel uint32 initial window size uint32 maximum packet size ... socket type specific data "udp" (might as well support "tcp" as well for completeness) string host to connect uint32 port to connect string originator IP address uint32 originator port "unix" string path to socket bool datagram (Never seen a use for AF_UNIX/SOCK_DGRAM personally but it is possible...) "named-pipe" string hostname string pipename uint32 flags Obviously still issues to work out with connection based vs. connectionless and reliability etc... But at the very least, the "unix"(SOCK_STREAM version) and "named-pipe" sockets could prove useful. -Sara From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 13:31:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWQy-0007Re-3x for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 13:31:36 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01741 for ; Wed, 31 Aug 2005 13:31:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7D68963B4E2; Wed, 31 Aug 2005 17:31:32 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 61ECD63B26F for ; Wed, 31 Aug 2005 17:31:31 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa11191; 31 Aug 2005 13:31 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7VHVLit009960 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 31 Aug 2005 13:31:22 -0400 (EDT) Date: Wed, 31 Aug 2005 13:31:21 -0400 From: Jeffrey Hutzelman To: Sara Golemon , ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) Message-ID: In-Reply-To: <015301c5ae4d$7cb18250$6c051fac@lighthammer> References: <015301c5ae4d$7cb18250$6c051fac@lighthammer> Originator-Info: login-token=Mulberry:01w17gky3GVQcPqVgU9twQAlrQF75Kklkw0w74+d4=; 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 Content-Transfer-Encoding: 7bit On Wednesday, August 31, 2005 10:00:07 -0700 Sara Golemon wrote: >> I was just wondering if there has ever been any >> thought put to making a draft of a UDP tunnel like the >> TCP forwarding function. >> > I was tossing this idea along with unix domain sockets/windows named > pipes and thought it might make more sense to define a generic "socket > tunnel" session or subsystem. Something like: I think something along these lines is a good idea. If you want to support forwarding in the reverse direction, you also need a generalized request for the server to listen on whatever sort of resource, and forward the connection back. > bool datagram (Never seen a use for AF_UNIX/SOCK_DGRAM > personally but it is possible...) I'm pretty sure I have; I just can't remember what offhand. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 13:39:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWYq-0001Yd-Tc for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 13:39:45 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02237 for ; Wed, 31 Aug 2005 13:39:43 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DB80463B4E6; Wed, 31 Aug 2005 17:39:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id F2A2763B26F for ; Wed, 31 Aug 2005 17:39:20 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A972DE0049; Wed, 31 Aug 2005 13:38:42 -0400 (EDT) To: Phillip Remaker Cc: Brian E Carpenter , galb-list@vandyke.com, Elwyn Davies , ietf-ssh@NetBSD.org, IESG Subject: Re: DISCUSS: draft-ietf-secsh-break-04 References: <43146D31.8060303@dial.pipex.com> <4315620D.1040206@zurich.ibm.com> <4315AED4.7040104@cisco.com> From: Sam Hartman Date: Wed, 31 Aug 2005 13:38:42 -0400 In-Reply-To: <4315AED4.7040104@cisco.com> (Phillip Remaker's message of "Wed, 31 Aug 2005 06:21:24 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Phillip" == Phillip Remaker writes: Phillip> Good point. I'm ambivalent, but I will copy ietf-ssh to Phillip> see what the opinion of the people who have already Phillip> developed the protoype code think. I did so yesterday and my reading of the consensus of that list is that I will add an rfc editor note removing the possibility that the break length field is absent. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 14:05:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWxX-0000q3-Of for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:05:15 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03547 for ; Wed, 31 Aug 2005 14:05:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1293763B4F2; Wed, 31 Aug 2005 18:05:11 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 3728563B4F0 for ; Wed, 31 Aug 2005 18:05:09 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA09773; Wed, 31 Aug 2005 14:05:08 -0400 (EDT) From: der Mouse Message-Id: <200508311805.OAA09773@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 31 Aug 2005 13:57:48 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) In-Reply-To: References: <015301c5ae4d$7cb18250$6c051fac@lighthammer> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> bool datagram (Never seen a use for AF_UNIX/SOCK_DGRAM >> personally but it is possible...) > I'm pretty sure I have; I just can't remember what offhand. Doing "fstat | egrep 'unix dgram'", I see syslog, plus a bunch of stuff of my own (most of my code using such sockets uses them to transfer file descriptors between processes at run time with SCM_RIGHTS, though there are exceptions). Whether there is value in forwarding AF_LOCAL sockets is questionable. Such forwarding will necessarily break certain facilities which some users of AF_LOCAL assume will work, such as SCM_CREDS, and I don't think it's unreasonable for code using AF_LOCAL sockets to blindly assume that both ends are running on the same machine (and thus, for example, agree on the size and byte order of ints).... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 14:05:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWxu-0000uc-OK for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:05:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03571 for ; Wed, 31 Aug 2005 14:05:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A94B763B4EF; Wed, 31 Aug 2005 18:05:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id 950F163B26F for ; Wed, 31 Aug 2005 18:05:33 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa11892; 31 Aug 2005 14:04 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j7VI3nre010142 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 31 Aug 2005 14:03:54 -0400 (EDT) Date: Wed, 31 Aug 2005 14:03:49 -0400 From: Jeffrey Hutzelman To: housley@vigilsec.com, iesg@ietf.org cc: galb@vandyke.com, jsalowey@cisco.com, welch@mcs.anl.gov, jhutz+@cmu.edu, sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Russ's comments on draft-ietf-secsh-gsskeyex-10.txt Message-ID: Originator-Info: login-token=Mulberry:01t0br9SGuYGkDkWN26sQbZE64IiA+emQkuxla7cY=; 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 Content-Transfer-Encoding: 7bit Russ made the following comments, which appear in the I-D tracker. > Since Base64 Encoding is used, but all of MIME is not used, it is > probably better to replace [MIME] with a reference to RFC 3548. I agree, the reference to RFC2045 section 6.8 can be replaced with a reference to RFC3548 section 3. The latter document didn't exist when this was written. I've made this change in my copy of the document source. > Please delete section 11 prior to publication as an RFC. Yes; that was always the intent. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 14:26:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXHp-0000kN-BF for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:26:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04638 for ; Wed, 31 Aug 2005 14:26:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CA73863B4F1; Wed, 31 Aug 2005 18:26:09 +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 260D263B26F for ; Wed, 31 Aug 2005 18:26:09 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7VIPoTW015528; Wed, 31 Aug 2005 12:25:51 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7VIPoWB008776; Wed, 31 Aug 2005 14:25:50 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7VIPnKc014277; Wed, 31 Aug 2005 14:25:49 -0400 (EDT) Subject: Re: DISCUSS: draft-ietf-secsh-break-04 From: Bill Sommerfeld To: Sam Hartman Cc: Phillip Remaker , Brian E Carpenter , Joseph Galbraith , Elwyn Davies , ietf-ssh@NetBSD.org, IESG In-Reply-To: References: <43146D31.8060303@dial.pipex.com> <4315620D.1040206@zurich.ibm.com> <4315AED4.7040104@cisco.com> Content-Type: text/plain Message-Id: <1125512748.13570.158.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 31 Aug 2005 14:25:49 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-08-31 at 13:38, Sam Hartman wrote: > Phillip> Good point. I'm ambivalent, but I will copy ietf-ssh to > Phillip> see what the opinion of the people who have already > Phillip> developed the protoype code think. > > I did so yesterday and my reading of the consensus of that list is > that I will add an rfc editor note removing the possibility that the > break length field is absent. That is my reading of the consensus as well. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 14:27:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXJG-0000uj-NL for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:27:42 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04698 for ; Wed, 31 Aug 2005 14:27:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D44B63B4F6; Wed, 31 Aug 2005 18:27:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 9A61663B4F5 for ; Wed, 31 Aug 2005 18:27:39 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1EAXJC-0005pN-00; Wed, 31 Aug 2005 19:27:38 +0100 From: Ben Harris To: jhutz@cmu.edu, ietf-ssh@NetBSD.org Subject: Re: Russ's comments on draft-ietf-secsh-gsskeyex-10.txt In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Wed, 31 Aug 2005 19:27:38 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >Russ made the following comments, which appear in the I-D tracker. > >> Since Base64 Encoding is used, but all of MIME is not used, it is >> probably better to replace [MIME] with a reference to RFC 3548. > >I agree, the reference to RFC2045 section 6.8 can be replaced with a >reference to RFC3548 section 3. The latter document didn't exist when this >was written. I've made this change in my copy of the document source. I observe that RFC 3548 is Informational, so by RFC 3967 the normative reference to it has to be mentioned in the Last Call notice for gsskeyex. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 14:29:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXLT-0001xr-9b for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:29:59 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04816 for ; Wed, 31 Aug 2005 14:29:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E4D063B4F5; Wed, 31 Aug 2005 18:29:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by mail.netbsd.org (Postfix) with ESMTP id 9957063B4F7 for ; Wed, 31 Aug 2005 18:29:51 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:50390) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EAXLI-00026m-4R (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Wed, 31 Aug 2005 19:29:48 +0100 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.52) id 1EAXLI-0007Gn-2j for ietf-ssh@netbsd.org; Wed, 31 Aug 2005 19:29:48 +0100 Date: Wed, 31 Aug 2005 19:29:48 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <015301c5ae4d$7cb18250$6c051fac@lighthammer> you write: >> I was just wondering if there has ever been any >> thought put to making a draft of a UDP tunnel like the >> TCP forwarding function. >> >I was tossing this idea along with unix domain sockets/windows named pipes >and thought it might make more sense to define a generic "socket tunnel" >session or subsystem. Something like: > > byte SSH_MSG_CHANNEL_OPEN > string "direct-socket" > string socket type name (e.g. "udp","unix","named-pipe") > uint32 sender channel > uint32 initial window size > uint32 maximum packet size The extra name in there breaks the format of SSH_MSG_CHANNEL_OPEN. Since you don't have any data specific to "direct-socket" apart from that name, it would be better to just make it part of the channel type (so "direct-udpip", "direct-unix", "direct-named-pipe"). -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 14:35:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXQk-0003aa-OP for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:35:26 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05039 for ; Wed, 31 Aug 2005 14:35:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4E67463B4FB; Wed, 31 Aug 2005 18:35:23 +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 9EE9663B19E for ; Wed, 31 Aug 2005 18:35:22 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7VIZ9DB003940; Wed, 31 Aug 2005 12:35:09 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7VIZ8Uj023853; Wed, 31 Aug 2005 14:35:08 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7VIZ8Wk014301; Wed, 31 Aug 2005 14:35:08 -0400 (EDT) Subject: Re: Russ's comments on draft-ietf-secsh-gsskeyex-10.txt From: Bill Sommerfeld To: Ben Harris Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org, Sam Hartman , Russ Housley In-Reply-To: References: Content-Type: text/plain Message-Id: <1125513307.13570.176.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 31 Aug 2005 14:35:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-08-31 at 14:27, Ben Harris wrote: > I observe that RFC 3548 is Informational, so by RFC 3967 the normative > reference to it has to be mentioned in the Last Call notice for gsskeyex. The IETF-wide last call period for gsskeyex; as I understand how 3967 is being implemented by the IESG, this would require another last-call cycle. Speaking just for myself, I don't think this degree of simplification is worth the delay it would apparently now require. As a side note, it appears that there isn't yet a repository listing informational rfc's which are ok to reference normatively from standards track documents. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 15:18:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAY63-0006We-9j for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 15:18:07 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07550 for ; Wed, 31 Aug 2005 15:18:04 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1084163B501; Wed, 31 Aug 2005 19:18:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 6040A63B19E for ; Wed, 31 Aug 2005 19:18:02 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7830216; Wed, 31 Aug 2005 13:18:01 -0600 Message-ID: <4316045A.5040001@vandyke.com> Date: Wed, 31 Aug 2005 13:26:18 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Ben Harris CC: ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ben Harris wrote: > In article <015301c5ae4d$7cb18250$6c051fac@lighthammer> you write: >>> I was just wondering if there has ever been any >>> thought put to making a draft of a UDP tunnel like the >>> TCP forwarding function. >>> >> I was tossing this idea along with unix domain sockets/windows named >> pipes >> and thought it might make more sense to define a generic "socket tunnel" >> session or subsystem. Something like: >> >> byte SSH_MSG_CHANNEL_OPEN >> string "direct-socket" >> string socket type name (e.g. "udp","unix","named-pipe") >> uint32 sender channel >> uint32 initial window size >> uint32 maximum packet size > > The extra name in there breaks the format of SSH_MSG_CHANNEL_OPEN. Since > you don't have any data specific to "direct-socket" apart from that > name, it > would be better to just make it part of the channel type (so > "direct-udpip", > "direct-unix", "direct-named-pipe"). Alternatively, the following format works: > byte SSH_MSG_CHANNEL_OPEN > string "direct-socket" > uint32 sender channel > uint32 initial window size > uint32 maximum packet size > string socket type name (e.g. "udp","unix","named-pipe") (I'm not commenting on which would be better... just that both are legal.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 16:41:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZOf-0006T8-Uw for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 16:41:28 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14084 for ; Wed, 31 Aug 2005 16:41:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9418D63B525; Wed, 31 Aug 2005 20:41:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by mail.netbsd.org (Postfix) with ESMTP id 32F4563B197 for ; Wed, 31 Aug 2005 20:41:18 +0000 (UTC) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id j7VK3JM1014611 for ; Wed, 31 Aug 2005 23:03:19 +0300 (EEST) Received: (qmail 4891 invoked from network); 31 Aug 2005 20:03:19 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.55]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 31 Aug 2005 20:03:19 -0000 Message-ID: <43160D2A.4010001@ssh.com> Date: Wed, 31 Aug 2005 23:03:54 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) References: <4316045A.5040001@vandyke.com> In-Reply-To: <4316045A.5040001@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi Since transporting datagrams over tcp tunnel is never performance efficient but can be useful for some other purpose (e.g. forwarding DNS in certain situations) I find it somewhat questionable if it's a good idea to define a channel type for this kind of use. UDP protocols often also need some other processing in addition to just forwarding. For example some kind of application gateway would be needed for protocols using portmapper. I made some tests a couple years ago with simple datagram forwarding sybsystem that implemented UDP forwarding over normal secsh subsystem channel. For DNS and NFS results were OK, however I never got to it ehough to make portmapper support so that NFS could have been run without considerable hand work. Anyways, it worked more or less nicely and took maybe 4 hours to implement. In addition to subsystem program only thing needed was a configuration change to secure shell server. In my opinion, subsystems in secure shell protocol exist for just this kind of use and implementing this stuff as channel types don't sound like very good idea. It is also worth mentioning that generic datagrams don't necessarily map directly to secure shell transport protocol packets so there will most likely be need of some kind of encapsulation for those datagrams before they would be sent as channel data. This encapsulation could as well be on subsystem level. Should someone be interested, I can probably release my subsystem protocol proto. //Rinne From owner-atom-syntax@mail.imc.org Wed Aug 31 16:41:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZOf-0006T7-4R for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 16:41:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14085 for ; Wed, 31 Aug 2005 16:41:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VKXWAj048730; Wed, 31 Aug 2005 13:33:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VKXWai048729; Wed, 31 Aug 2005 13:33:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7VKXUjf048703 for ; Wed, 31 Aug 2005 13:33:31 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 Aug 2005 20:33:24 -0000 Received: from xdsl-81-173-169-77.netcologne.de (EHLO klangraum) [81.173.169.77] by mail.gmx.net (mp007) with SMTP; 31 Aug 2005 22:33:24 +0200 X-Authenticated: #163624 Date: Wed, 31 Aug 2005 22:33:33 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: The benefits of "Lists are Entries" rather than "Lists are Feeds" Message-ID: <20050831203333.GA10254@klangraum> Mail-Followup-To: Atom Syntax References: <20050830210957.2DB257244B5@mail.pubsub.com> <20050831153620.8B6B2725B7E@mail.pubsub.com> <540e373205083110224cd8c779@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14085 * Graham [2005-08-31 20:40]: > On 31 Aug 2005, at 6:22 pm, Roger B. wrote: > >(1) If the lists are embedded as (X)HTML, then only > >aggregators that display markup will be able to do anything > >with them, and headline-only aggregators will be useless. >=20 > And damn those unthinking bloggers who embed their paragraphs > as (X) HTML, because headline-only aggregators are useless for > reading them. Straw man. These bloggers are embedding the content of a single entry in each single entry, not the content of a collection of entries. > >(2) If the lists are embedded in a new extension of some sort, > >developers have to buy in to get even minimal functionality. >=20 > Who is advocating this? I don=E2=80=99t know about advocating, but it has been mentioned. > Another feature is the list can be formatted properly XHTML, > considerably improving legibly over a bunch of floating > entries. Straw man. The onus for the legibility of an XHTML-formatted list lies with the publisher; for the entries-as-items list, it lies with the aggregator developer. I=E2=80=99m sorry if you aggregator developer can=E2=80=99t make a bunch of floating entries very readable. Regards, --=20 Aristotle Pagaltzis // From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 16:48:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZVR-0007tl-1B for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 16:48:25 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14238 for ; Wed, 31 Aug 2005 16:48:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CFF7463B529; Wed, 31 Aug 2005 20:48:21 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 0136B63B197 for ; Wed, 31 Aug 2005 20:48:20 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa22517; 31 Aug 2005 16:47 EDT Date: Wed, 31 Aug 2005 16:47:35 -0400 From: Jeffrey Hutzelman To: Bill Sommerfeld , Ben Harris cc: ietf-ssh@NetBSD.org, Sam Hartman , Russ Housley , iesg@ietf.org Subject: Re: Russ's comments on draft-ietf-secsh-gsskeyex-10.txt Message-ID: <8E10A9D72151572600510EF1@sirius.fac.cs.cmu.edu> In-Reply-To: <1125513307.13570.176.camel@thunk> References: <1125513307.13570.176.camel@thunk> Originator-Info: login-token=Mulberry:01v4qM/ynyAXML1QSA8gi8blb8wypGvgUs/7pk9Qo=; 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 Content-Transfer-Encoding: 7bit [My original message was CC'd to my coauthors and to the IESG. I don't know why they were dropped in Ben's reply; I've readded the IESG but will assume my coauthors read the ietf-ssh list]. On Wednesday, August 31, 2005 02:35:08 PM -0400 Bill Sommerfeld wrote: > On Wed, 2005-08-31 at 14:27, Ben Harris wrote: >> I observe that RFC 3548 is Informational, so by RFC 3967 the normative >> reference to it has to be mentioned in the Last Call notice for gsskeyex. > > The IETF-wide last call period for gsskeyex; as I understand how 3967 is > being implemented by the IESG, this would require another last-call > cycle. > > Speaking just for myself, I don't think this degree of simplification is > worth the delay it would apparently now require. > > As a side note, it appears that there isn't yet a repository listing > informational rfc's which are ok to reference normatively from standards > track documents. I agree that this level of simplification is not worth another IETF last call. Since Ben's comment is included above, the IESG should now be aware of the issue; let's let them decide if the reference can be updated without a new last call, or if it should be left as-is. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 18:05:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAahd-0003CF-Ef for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 18:05:05 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18632 for ; Wed, 31 Aug 2005 18:05:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2807C63B14A; Wed, 31 Aug 2005 22:04:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id 6BFC263B128 for ; Wed, 31 Aug 2005 22:04:58 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 65B8AE0049; Wed, 31 Aug 2005 18:04:23 -0400 (EDT) To: Jeffrey Hutzelman Cc: Bill Sommerfeld , Ben Harris , ietf-ssh@NetBSD.org, Russ Housley , iesg@ietf.org Subject: Re: Russ's comments on draft-ietf-secsh-gsskeyex-10.txt References: <1125513307.13570.176.camel@thunk> <8E10A9D72151572600510EF1@sirius.fac.cs.cmu.edu> From: Sam Hartman Date: Wed, 31 Aug 2005 18:04:23 -0400 In-Reply-To: <8E10A9D72151572600510EF1@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 31 Aug 2005 16:47:35 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> [My original message was CC'd to my coauthors and to the Jeffrey> IESG. I don't know why they were dropped in Ben's reply; Jeffrey> I've readded the IESG but will assume my coauthors read Jeffrey> the ietf-ssh list]. Jeffrey> On Wednesday, August 31, 2005 02:35:08 PM -0400 Bill Jeffrey> Sommerfeld Jeffrey> wrote: >> On Wed, 2005-08-31 at 14:27, Ben Harris wrote: >>> I observe that RFC 3548 is Informational, so by RFC 3967 the >>> normative reference to it has to be mentioned in the Last Call >>> notice for gsskeyex. >> The IETF-wide last call period for gsskeyex; as I understand >> how 3967 is being implemented by the IESG, this would require >> another last-call cycle. >> >> Speaking just for myself, I don't think this degree of >> simplification is worth the delay it would apparently now >> require. >> >> As a side note, it appears that there isn't yet a repository >> listing informational rfc's which are ok to reference >> normatively from standards track documents. Jeffrey> I agree that this level of simplification is not worth Jeffrey> another IETF last call. Since Ben's comment is included Jeffrey> above, the IESG should now be aware of the issue; let's Jeffrey> let them decide if the reference can be updated without a Jeffrey> new last call, or if it should be left as-is. I believe it would require another last call; I will not update the rfc editor note to make this simplification. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 21:44:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAe7W-0002dZ-Ve for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 21:44:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01434 for ; Wed, 31 Aug 2005 21:44:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 730FF63B537; Thu, 1 Sep 2005 01:43:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fsau.vintela.com (unknown [202.183.100.57]) by mail.netbsd.org (Postfix) with ESMTP id BB0B763B535 for ; Thu, 1 Sep 2005 01:43:58 +0000 (UTC) Received: from lark.vintela.com (lark.vintela.com [10.20.36.133]) by fsau.vintela.com (Postfix) with ESMTP id 15C9232E3F for ; Thu, 1 Sep 2005 11:43:55 +1000 (EST) Date: Thu, 1 Sep 2005 11:43:52 +1000 (EST) From: David Leonard X-X-Sender: davidl@lark.vintela.com To: ietf-ssh@NetBSD.org Subject: gskeykex - Delete_sec_context() on re-key Message-ID: Organization: Vintela; Quest Software MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list I was reading through the secsh-gsskeyex draft again and it struck me that when re-keying there is no message provision for passing back the possible token generated by a call to GSS_Delete_sec_context(). The result is that the protocol will leak unreachable context over a long session. Has anyone hit this? I'm seeing something here where I think I'm exhausting the number of simultaneous contexts the GSS implementation can handle. d -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 21:56:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAeJs-0005Rg-Dx for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 21:56:51 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01885 for ; Wed, 31 Aug 2005 21:56:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C4A6A63B538; Thu, 1 Sep 2005 01:56:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id 1735763B535 for ; Thu, 1 Sep 2005 01:56:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 604B234E8D; Thu, 1 Sep 2005 13:56:43 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02437-05; Thu, 1 Sep 2005 13:56:43 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 4362334567; Thu, 1 Sep 2005 13:56:41 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BD0B43775B; Thu, 1 Sep 2005 13:56:41 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EAeJp-0006cL-00; Thu, 01 Sep 2005 13:56:45 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, fcusack@fcusack.com, ietf-ssh@NetBSD.org Subject: Re: New draft possibilities In-Reply-To: Message-Id: Date: Thu, 01 Sep 2005 13:56:45 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Harris writes: >In article <15F6428B71F2CC3D02A44AE0@maguro.savecore.net> you write: >>Or were IP protocoles not really used over X.25? > >They certainly were. When I arrived at University in 1994, we had a 2 >Mbit X.25 connection over which we ran IP. Did you ever manage to achieve more than 50% link utilisation? Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 22:57:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfGE-000306-7u for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 22:57:06 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04144 for ; Wed, 31 Aug 2005 22:57:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 29B3063B535; Thu, 1 Sep 2005 02:57:02 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 3E65A63B4E1 for ; Thu, 1 Sep 2005 02:57:01 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa22811; 31 Aug 2005 22:56 EDT Date: Wed, 31 Aug 2005 22:56:35 -0400 From: Jeffrey Hutzelman To: David Leonard , ietf-ssh@NetBSD.org Subject: Re: gskeykex - Delete_sec_context() on re-key Message-ID: <606125828F4E72329EA38418@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01t3qhbSHiFuEDxRnu6vjR3E7s2Jg+rhok78/S7fo=; 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 Content-Transfer-Encoding: 7bit On Thursday, September 01, 2005 11:43:52 AM +1000 David Leonard wrote: > I was reading through the secsh-gsskeyex draft again and it struck > me that when re-keying there is no message provision for passing back the > possible token generated by a call to GSS_Delete_sec_context(). That's correct. When you're done with a context, which in this protocol means pretty much as soon as key exchange has completed successfully, you can just call GSS_Delete_sec_context() without an output token buffer, regardless of whether you are the client or server. The only purpose of an output token from this call is to signal _via a context token_ that the context should be destroyed. In this protocol, you don't need to do that, because you always know out-of-band when the context can be deleted. > The result is that the protocol will leak unreachable context > over a long session. Only if you fail to call GSS_Delete_sec_context() with a context when you are done using it. Note that you do _not_ need to keep the context around for the life of the session -- it's only used during key exchange. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 31 23:55:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAgAM-0001K1-CR for secsh-archive@megatron.ietf.org; Wed, 31 Aug 2005 23:55:06 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06539 for ; Wed, 31 Aug 2005 23:55:02 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1C25363B549; Thu, 1 Sep 2005 03:55:03 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id E054F63B544 for ; Thu, 1 Sep 2005 03:55:01 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA11937; Wed, 31 Aug 2005 23:55:00 -0400 (EDT) From: der Mouse Message-Id: <200509010355.XAA11937@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 31 Aug 2005 23:52:41 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) In-Reply-To: <4316045A.5040001@vandyke.com> References: <4316045A.5040001@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> The extra name in there breaks the format of SSH_MSG_CHANNEL_OPEN. >> Since you don't have any data specific to "direct-socket" apart from >> that name, it would be better to just make it part of the channel >> type (so "direct-udpip", "direct-unix", "direct-named-pipe"). > Alternatively, the following format works: [type name at end] > (I'm not commenting on which would be better... just that both are > legal.) In case anyone cares what I think - I'd prefer one channel type with a subtype field ("direct-socket" with "udp", "named-pipe", etc). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B