From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 2 19:59:32 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03881 for ; Wed, 2 Feb 2005 19:59:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 52A9751F3; Thu, 3 Feb 2005 00:59:22 +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 60B4F518A for ; Thu, 3 Feb 2005 00:59:20 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa05555; 2 Feb 2005 19:59 EST Date: Wed, 02 Feb 2005 19:59:04 -0500 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: DH KEX names an "aberration"? Message-ID: Originator-Info: login-token=Mulberry:015iEuKVCJo50ybKaqGZ9emH2TZVRtVadTllyOHKE=; 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 In preparing a response to a message on another list, I went back to the current transport draft to check on what the outcome was of the DH key exchange group naming debate. I found the following text: Note that, for historical reasons, the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. This is considered an aberration and should not be repeated. Any future specifications of Diffie-Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be performed with care and a bit of research. Now, I remember arguing that we should name these things based on the group numbers assigned in RFC2412 and its successors, and that "group1" was an aberration. And, I remember other people arguing that we should treat "group1" as existing practice to be followed, and assign our own names independent of those assigned in RFC2412. The text above implies that we chose to follow the existing numbering scheme and use "group14", but that also that we consider _that_ an "aberration" and something to be avoided in the future. That just doesn't make any sense to me -- if we decided we should use our own naming scheme, why use "group14" at all. And if we decided not to use our own naming scheme, why does the document essentially say that was a bad decision? Also, while I don't disagree with the last sentence in principle, it seems to be implying that the current work was not "performed with care and a bit of research". Given the amount of debate and, yes, research that went into that decision, that seems inappropriate here. What happened here? -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 3 03:16:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27912 for ; Thu, 3 Feb 2005 03:16:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9DC8B52A0; Thu, 3 Feb 2005 08:16:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id 2F894519B for ; Thu, 3 Feb 2005 08:16:24 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id C2FB31B8033; Thu, 3 Feb 2005 09:16:22 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 22197-01-4; Thu, 3 Feb 2005 09:16:17 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 1F9201B807D; Thu, 3 Feb 2005 09:16:17 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j138GGsA017305; Thu, 3 Feb 2005 09:16:16 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j138GBWH017300; Thu, 3 Feb 2005 09:16:11 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 03 Feb 2005 09:16:10 +0100 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > Note that, for historical reasons, the name > "diffie-hellman-group1-sha1" is used for a key exchange method using > an Oakley group as defined in [RFC2412]. Subsequently, the Working > Group attempted to follow the numbering scheme of group numbers from > [RFC3526] with diffie-hellman-group14-sha1 for the name of the second > defined name. This is considered an aberration and should not be > repeated. > The text above implies that we chose to follow the existing numbering > scheme and use "group14", but that also that we consider _that_ an > "aberration" and something to be avoided in the future. That just > doesn't make any sense to me -- if we decided we should use our own > naming scheme, why use "group14" at all. And if we decided not to use > our own naming scheme, why does the document essentially say that was > a bad decision? I agree the text is a little confusing. Given that there was no consensus on the preferred naming style, and that both the current choices were motivated by compatibility by the deployed implementations, I don't think it's appropriate to say that either name is an "aberration". We might need to comment the inconsistent naming, though. > Any future specifications of Diffie-Hellman key exchange > using Oakley groups defined in [RFC2412] or its successors should be > performed with care and a bit of research. > Also, while I don't disagree with the last sentence in principle, it > seems to be implying that the current work was not "performed with > care and a bit of research". I think the important message here is that adopting new Oakley groups is not a mere formality; one shouldn't expect that oakley group 17 is automatically given the name diffie-hellman-group17-sha1 and be supported in the ssh protocol. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 3 11:54:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14647 for ; Thu, 3 Feb 2005 11:54:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CDE5E5503; Thu, 3 Feb 2005 16:53:59 +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 754CF51CB for ; Thu, 3 Feb 2005 16:53:57 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa06966; 3 Feb 2005 11:53 EST Date: Thu, 03 Feb 2005 11:53:49 -0500 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:019nMIdWDbfelCvoD2KfE45I3lP6B9p4Fj6DbaLPM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Thursday, February 03, 2005 09:16:10 AM +0100 Niels M=F6ller=20 wrote: > Jeffrey Hutzelman writes: > >> Note that, for historical reasons, the name >> "diffie-hellman-group1-sha1" is used for a key exchange method using >> an Oakley group as defined in [RFC2412]. Subsequently, the Working >> Group attempted to follow the numbering scheme of group numbers from >> [RFC3526] with diffie-hellman-group14-sha1 for the name of the second >> defined name. This is considered an aberration and should not be >> repeated. > >> The text above implies that we chose to follow the existing numbering >> scheme and use "group14", but that also that we consider _that_ an >> "aberration" and something to be avoided in the future. That just >> doesn't make any sense to me -- if we decided we should use our own >> naming scheme, why use "group14" at all. And if we decided not to use >> our own naming scheme, why does the document essentially say that was >> a bad decision? > > I agree the text is a little confusing. Given that there was no > consensus on the preferred naming style, and that both the current > choices were motivated by compatibility by the deployed > implementations, I don't think it's appropriate to say that either > name is an "aberration". We might need to comment the inconsistent > naming, though. Well, in an ideal world, the WG would come to some consensus on which=20 naming form we should use. Then we could state which convention the WG had = decided to adopt, and indicate that the non-conformant name was used in=20 order to promote interoperability with deployed implementations. I'd much=20 rather have this debate resolved once and for all than have the same=20 argument every time we go to add new groups. Is this the issue we had Nico flip a coin for, or was that something else? >> Any future specifications of Diffie-Hellman key exchange >> using Oakley groups defined in [RFC2412] or its successors should be >> performed with care and a bit of research. > >> Also, while I don't disagree with the last sentence in principle, it >> seems to be implying that the current work was not "performed with >> care and a bit of research". > > I think the important message here is that adopting new Oakley groups > is not a mere formality; one shouldn't expect that oakley group 17 is > automatically given the name diffie-hellman-group17-sha1 and be > supported in the ssh protocol. In fact, one shouldn't assume it gets any particular name or is=20 automatically supported. Perhaps we just need to point out that key=20 exchange names are in general not constructed, and each variation must be=20 defined and registered explicitly. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 3 18:11:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04445 for ; Thu, 3 Feb 2005 18:11:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 475E6531D; Thu, 3 Feb 2005 23:11: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 9E9CD51C9 for ; Thu, 3 Feb 2005 23:11:02 +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 j13N1Tdt008048 for ; Thu, 3 Feb 2005 16:01:29 -0700 (MST) Received: from thunk (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 j13N1SOp029570; Thu, 3 Feb 2005 18:01:29 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j13N1SXJ022003; Thu, 3 Feb 2005 18:01:28 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j13N1SfO022002; Thu, 3 Feb 2005 18:01:28 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: FYI: draft-ietf.ipr-trademarks-00.txt From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107471688.19687.141.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 03 Feb 2005 18:01:28 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit There is a new I-D just published proposing a process clarification on how IETF documents should reference trademarks; if approved by the IESG, this will remove the largest current obstacle to publication of the secure shell core documents. Note that discussions of the specifics of this document are off-topic here; if you have comments or concerns about this proposal, discussion should occur on the IETF IPR WG list, ipr-wg@ietf.org - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 11:18:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11299 for ; Fri, 4 Feb 2005 11:18:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E3695351; Fri, 4 Feb 2005 16:18:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.netbsd.org (Postfix) with ESMTP id D5DDA5166 for ; Fri, 4 Feb 2005 16:18:10 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 04 Feb 2005 08:18:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14GI5oQ027196 for ; Fri, 4 Feb 2005 08:18:06 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA26095 for ; Fri, 4 Feb 2005 08:18:08 -0800 (PST) Date: Fri, 4 Feb 2005 08:18:08 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, The coin toss was for this subject. Please read over the prior and current text and let me know if the proposed text sounds good. Wordsmithing would be appreciated. Past - [TRANS]-21: Additional methods may be defined as specified in [SSH-NUMBERS]. Note that, for historical reasons, the name "diffie-hellman-group1-sha1" is used for a key exchange method using Oakley Group 2. This is considered an aberration and should not be repeated. Any future specifications of Diffie Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be named using the group numbers assigned by IANA, and names of the form "diffie-hellman-groupN-sha1" should be reserved for this purpose. Current - [TRANS]-22: Additional methods may be defined as specified in [SSH-NUMBERS]. Note that, for historical reasons, the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. This is considered an aberration and should not be repeated. Any future specifications of Diffie-Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be performed with care and a bit of research. Proposed - [TRANS]-next Additional methods may be defined as specified in [SSH-NUMBERS]. Note that for historical reasons the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. This inconsistency should not be repeated. The naming of future specifications of Diffie-Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be performed with forethought and care. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 11:37:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12677 for ; Fri, 4 Feb 2005 11:37:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BBE515497; Fri, 4 Feb 2005 16:36:40 +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 C9F3454C8 for ; Fri, 4 Feb 2005 16:36:34 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7112530; Fri, 04 Feb 2005 09:36:32 -0700 Message-ID: <4203A495.8080203@vandyke.com> Date: Fri, 04 Feb 2005 09:36:37 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Chris Lonvick wrote: > Hi, > > The coin toss was for this subject. Please read over the prior and > current text and let me know if the proposed text sounds good. > Wordsmithing would be appreciated. > > Past - [TRANS]-21: > > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that, for historical reasons, the name > "diffie-hellman-group1-sha1" is used for a key exchange method using > Oakley Group 2. This is considered an aberration and should not be > repeated. Any future specifications of Diffie Hellman key exchange > using Oakley groups defined in [RFC2412] or its successors should be > named using the group numbers assigned by IANA, and names of the form > "diffie-hellman-groupN-sha1" should be reserved for this purpose. > > Current - [TRANS]-22: > > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that, for historical reasons, the name > "diffie-hellman-group1-sha1" is used for a key exchange method using > an Oakley group as defined in [RFC2412]. Subsequently, the Working > Group attempted to follow the numbering scheme of group numbers from > [RFC3526] with diffie-hellman-group14-sha1 for the name of the second > defined name. This is considered an aberration and should not be > repeated. Any future specifications of Diffie-Hellman key exchange > using Oakley groups defined in [RFC2412] or its successors should be > performed with care and a bit of research. > > Proposed - [TRANS]-next > > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that for historical reasons the name > "diffie-hellman-group1-sha1" is used for a key exchange method using > an Oakley group as defined in [RFC2412]. Subsequently, the Working > Group attempted to follow the numbering scheme of group numbers from > [RFC3526] with diffie-hellman-group14-sha1 for the name of the second > defined name. This inconsistency should not be repeated. The naming > of future specifications of Diffie-Hellman key exchange using Oakley > groups defined in [RFC2412] or its successors should be performed > with forethought and care. I don't recall the results of the coin toss, and it isn't clear from this. So how about one of the following, depending on which way the toss went: Additional methods may be defined as specified in [SSH-NUMBERS]. Note that for historical reasons the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. Future groups borrowed from [RFC2412] should continue to use the same numbering scheme used by [RFC3526]. However, without specific IETF action, no addition groups from [RFC3526] are valid in the SSH protocol. OR: Additional methods may be defined as specified in [SSH-NUMBERS]. Note that for historical reasons the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. Future groups borrowed from [RFC2412] should not attemp to use the same numbering scheme used by [RFC3526], but should use numbering unique to SSH. I.e., the next group defined for SSH should be diffie-hellman-group2-sha1, regardless of it's source. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 12:42:32 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18435 for ; Fri, 4 Feb 2005 12:42:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4563A5348; Fri, 4 Feb 2005 17:42:25 +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 17FF551EA for ; Fri, 4 Feb 2005 17:42:22 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa12173; 4 Feb 2005 12:41 EST Date: Fri, 04 Feb 2005 12:40:58 -0500 From: Jeffrey Hutzelman To: Joseph Galbraith , Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? Message-ID: In-Reply-To: <4203A495.8080203@vandyke.com> References: <4203A495.8080203@vandyke.com> Originator-Info: login-token=Mulberry:01iOAvFPJIpIjUK6eVu15fgx9SZj8PFKj1VV15vmA=; 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, February 04, 2005 09:36:37 AM -0700 Joseph Galbraith wrote: > Chris Lonvick wrote: >> [...] This inconsistency should not be repeated. The naming >> of future specifications of Diffie-Hellman key exchange using Oakley >> groups defined in [RFC2412] or its successors should be performed >> with forethought and care. > > I don't recall the results of the coin toss, and it isn't > clear from this. So how about one of the following, depending > on which way the toss went: > > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that for historical reasons the name > "diffie-hellman-group1-sha1" is used for a key exchange method using > an Oakley group as defined in [RFC2412]. Subsequently, the Working > Group attempted to follow the numbering scheme of group numbers from > [RFC3526] with diffie-hellman-group14-sha1 for the name of the second > defined name. Future groups borrowed from [RFC2412] should continue > to use the same numbering scheme used by [RFC3526]. However, without > specific IETF action, no addition groups from [RFC3526] are valid in > the SSH protocol. > > OR: > > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that for historical reasons the name > "diffie-hellman-group1-sha1" is used for a key exchange method using > an Oakley group as defined in [RFC2412]. Subsequently, the Working > Group attempted to follow the numbering scheme of group numbers from > [RFC3526] with diffie-hellman-group14-sha1 for the name of the second > defined name. Future groups borrowed from [RFC2412] should not attemp > to use the same numbering scheme used by [RFC3526], but should > use numbering unique to SSH. I.e., the next group defined for SSH > should be diffie-hellman-group2-sha1, regardless of it's source. I think I prefer the phrasing "[RFC2412] and its successors". Otherwise, Joseph's text looks good. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 14:06:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24356 for ; Fri, 4 Feb 2005 14:06:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 037C85198; Fri, 4 Feb 2005 19:06:30 +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 C2540517C for ; Fri, 4 Feb 2005 19:06:27 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa12279; 4 Feb 2005 14:04 EST Date: Fri, 04 Feb 2005 14:04:41 -0500 From: Jeffrey Hutzelman To: denis bider , "'Joseph Galbraith'" , "'Chris Lonvick'" Cc: ietf-ssh@NetBSD.org Subject: RE: DH KEX names an "aberration"? Message-ID: <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> In-Reply-To: <000001c50ae9$96dd7240$d7b7fea9@nucleus> References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> Originator-Info: login-token=Mulberry:01aczQvdM0RTG1F0g+nEoALAA+B+jwAEnWQf4in0w=; 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, February 04, 2005 07:44:39 PM +0100 denis bider wrote: >> I think I prefer the phrasing "[RFC2412] and its successors". >> Otherwise, Joseph's text looks good. > > Looks good to me too. > > It is my impression that the second variant is where we are headed, i.e., > with Jeffrey's nit, like this: > > >> Additional methods may be defined as specified in [SSH-NUMBERS]. >> Note that for historical reasons the name "diffie-hellman-group1-sha1" >> is used for a key exchange method using an Oakley group as defined >> in [RFC2412]. Subsequently, the Working Group attempted to follow >> the numbering scheme of group numbers from [RFC3526] with >> diffie-hellman-group14-sha1 for the name of the second defined name. So far, so good - these groups come from specific documents >> Future groups borrowed from [RFC2412] and its successors should not But "future groups" could come from any of this series of documents, so again, this is the right phrasing. >> attempt to use the same numbering scheme used by [RFC3526], but The numbering scheme is shared by all the documents, not just this one. How about something like... >> Future groups borrowed from [RFC2412] and its successors { should >> continue | should not attempt } to use the same numbering scheme >> used in those documents... I really don't recall the results of the coin flip. A quick check of the proceedings shows: > ticket 460, 601: no consensus on list. > flipped coin, heads for "group2", tails for "group14", came up tails > will stick with diffie-hellman-group14-sha1 That implies the coin flip was only intended to apply to that one decision, and not to set a direction for future naming. Bill, can you comment on this? I'd prefer to have a direction for future naming, but not at the expense of delaying things indefinitely. If we can agree on a direction, or accept the coin toss as setting one, then we should use one of Joseph's proposed paragraphs (modulo the wordsmithing we've just done). Otherwise, if/when it is time to submit new documents to resolve the trademark issue, I think we should use Chris's proposed text, which cleans up the explanation of the situation while still leaving the long-term question unresolved. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 15:25:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01376 for ; Fri, 4 Feb 2005 15:25:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AEACB553F; Fri, 4 Feb 2005 20:25:23 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from conqueror.cnchost.com (conqueror.cnchost.com [207.155.248.122]) by mail.netbsd.org (Postfix) with ESMTP id 01ED8516C for ; Fri, 4 Feb 2005 20:25:21 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by conqueror.cnchost.com id NAA05327; Fri, 4 Feb 2005 13:44:43 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Jeffrey Hutzelman'" , "'Joseph Galbraith'" , "'Chris Lonvick'" Cc: Subject: RE: DH KEX names an "aberration"? Date: Fri, 4 Feb 2005 19:44:39 +0100 Message-ID: <000001c50ae9$96dd7240$d7b7fea9@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > I think I prefer the phrasing "[RFC2412] and its successors". > Otherwise, Joseph's text looks good. Looks good to me too. It is my impression that the second variant is where we are headed, i.e., with Jeffrey's nit, like this: > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that for historical reasons the name "diffie-hellman-group1-sha1" > is used for a key exchange method using an Oakley group as defined > in [RFC2412]. Subsequently, the Working Group attempted to follow > the numbering scheme of group numbers from [RFC3526] with > diffie-hellman-group14-sha1 for the name of the second defined name. > Future groups borrowed from [RFC2412] and its successors should not > attempt to use the same numbering scheme used by [RFC3526], but > should use numbering unique to SSH. I.e., the next group defined for > SSH should be diffie-hellman-group2-sha1, regardless of its source. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 15:33:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02092 for ; Fri, 4 Feb 2005 15:33:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5091D5543; Fri, 4 Feb 2005 20:33:37 +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 737A2516C for ; Fri, 4 Feb 2005 20:33:35 +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 j14KWNVu005462; Fri, 4 Feb 2005 13:32:23 -0700 (MST) Received: from thunk (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 j14KWMQp026662; Fri, 4 Feb 2005 15:32:22 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j14KWMwV027679; Fri, 4 Feb 2005 15:32:22 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j14KWLas027678; Fri, 4 Feb 2005 15:32:21 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: DH KEX names an "aberration"? From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: denis bider , "'Joseph Galbraith'" , "'Chris Lonvick'" , ietf-ssh@NetBSD.org In-Reply-To: <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1107549140.27425.27.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 04 Feb 2005 15:32:21 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-02-04 at 14:04, Jeffrey Hutzelman wrote: > > ticket 460, 601: no consensus on list. > > flipped coin, heads for "group2", tails for "group14", came up tails > > will stick with diffie-hellman-group14-sha1 > > That implies the coin flip was only intended to apply to that one decision, > and not to set a direction for future naming. Bill, can you comment on > this? correct. it was intended only for that one decision. > I'd prefer to have a direction for future naming, but not at the expense of > delaying things indefinitely. If we can agree on a direction, or accept > the coin toss as setting one, then we should use one of Joseph's proposed > paragraphs (modulo the wordsmithing we've just done). (wg chair hat off) For future direction, my preference would be to do something which doesn't involve us arguing over which small integer refers to a which large integer. but who am I to interfere with what appears to be gathering consensus.. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 4 18:12:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17736 for ; Fri, 4 Feb 2005 18:12:08 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DD3CB55AE; Fri, 4 Feb 2005 23:10:42 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 82780517F for ; Fri, 4 Feb 2005 23:10:40 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Feb 2005 16:21:27 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14NAYoQ019775 for ; Fri, 4 Feb 2005 15:10:34 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA25608 for ; Fri, 4 Feb 2005 15:10:37 -0800 (PST) Date: Fri, 4 Feb 2005 15:10:37 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: FYI: draft-ietf.ipr-trademarks-00.txt In-Reply-To: <1107471688.19687.141.camel@thunk> Message-ID: References: <1107471688.19687.141.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, [TRANS] has the following text: The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. Arcfour (and RC4) has problems with weak keys, and should be used with caution. Pursuant to Section 3 of draft-ietf.ipr-trademarks-00.txt I will be removing the statement of trademark. == 3. No IPR disclosures in IETF Documents To conform to the requirements of RFC 3668, the contribution must not include a statement such as "Foo (TM) is a trademark of BarrCo." ... == Thanks, Chris On Thu, 3 Feb 2005, Bill Sommerfeld wrote: > There is a new I-D just published proposing a process clarification > on how IETF documents should reference trademarks; if approved by the > IESG, this will remove the largest current obstacle to publication of the > secure shell core documents. > > Note that discussions of the specifics of this document are off-topic here; > if you have comments or concerns about this proposal, discussion should occur on the IETF IPR WG list, ipr-wg@ietf.org > > - Bill > > > > > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 7 16:34:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23278 for ; Mon, 7 Feb 2005 16:34:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9321251E3; Mon, 7 Feb 2005 21:34:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.netbsd.org (Postfix) with ESMTP id E3F395184 for ; Mon, 7 Feb 2005 21:34:02 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2005 13:35:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17LY0uC005693 for ; Mon, 7 Feb 2005 13:34:00 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA13476 for ; Mon, 7 Feb 2005 13:34:00 -0800 (PST) Date: Mon, 7 Feb 2005 13:34:00 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: RE: DH KEX names an "aberration"? In-Reply-To: <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> Message-ID: References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Way back in time, the WG agreed to use diffie-hellman-group2-sha1 for the second defined kex method. We never put that into any of the IDs as we started discussing "proper naming". I believe it was early last year and we went for some time before we got into the discussion of associating the number used with the group to the "group" number defined in RFC3526. This led us to agree to use diffie-hellman-group14-sha1 and that's the way it became in [TRANS]-19 and continues this way in the IDs. Tero Kevininen pointed out (in August) that "14" should probably not be used as that wasn't going to be a consistently referenceable number for the future. This led some to think about going back to "2" but others argued that "14" was in shipping code. The coin toss resulted in us agreeing to use "14" but we did not mention what we were to do with "2" nor with what we were to do about recommending future naming schemes. I was hoping to duck that issue which I will now name "the briar patch issue". (Every time I try to crawl out of it, I get stuck worse.) Going with the assumption that those who forget history are doomed to repeat it, I'll propose the following text: Additional methods may be defined as specified in [SSH-NUMBERS]. Note that the name "diffie-hellman-group1-sha1" is used for the first defined key exchange method using an Oakley group referenced from [RFC2412]. The Working Group first attempted to progress the namespace scheme by using "diffie-hellman-group2-sha1" for the second defined key exchange (kex) name. This name was never used in any Working Group documents but was discussed in the mailing list. It is not known if this kex name was implemented in any shipping code. During this deliberation period, the Working Group wanted to provide for a better naming scheme and attempted to follow the numbering scheme of group numbers from [RFC3526]. This resulted in the selection of "diffie-hellman-group14-sha1" rather than "diffie-hellman-group2-sha1" which the Working Group felt was not as descriptive. After this name was generally approved by consensus and started appearing in subsequent Internet Drafts (and shipping code), it was noted that the numbers associated with the groups in [RFC3526] were assigned by the IANA and may be changed in the future, or that numbers may not be used at all. This caused some indecision within the Working Group which was resolved at the Working Group meeting at the 60th IETF with the formal adoption of the "diffie-hellman-group14-sha1" name for the second defined kex method. This inconsistency should not be repeated in the future. Future groups borrowed from [RFC2412] or its successors should not attempt to associate SSH kex algorithms with numbers from [RFC3526]. The naming of future specifications of Diffie-Hellman kex methods using Oakley groups defined in [RFC2412] or its successors should be performed with forethought and care. It will probably be best if future names are unique to SSH and not dependent upon any external naming or numbering schemes. Authors of future kex proposals may wish to consider the use of "diffie-hellman-group3-sha1" or "diffie-hellman-group15-sha1" for the next name. I'll take input on the following which may modify this text: - Did anyone actually use "diffie-hellman-group2-sha1" in shipping code? - Should we state that "2" has been poisoned because of that? - Should we leave it as use "3" or "15" next? (If anyone responds with "no" then they'll have to propose something better.) --prior discussion elided for brevity-- Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 7 16:56:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29438 for ; Mon, 7 Feb 2005 16:56:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 27B525243; Mon, 7 Feb 2005 21:56:39 +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 8F85951DE for ; Mon, 7 Feb 2005 21:56:36 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa30718; 7 Feb 2005 16:56 EST Date: Mon, 07 Feb 2005 16:56:31 -0500 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: RE: DH KEX names an "aberration"? Message-ID: <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> In-Reply-To: References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> Originator-Info: login-token=Mulberry:01Qv1cUaxl0cWOSNTSdXuMwNlvk3zJMdWvcoq2eH0=; 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, February 07, 2005 01:34:00 PM -0800 Chris Lonvick wrote: > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that the name "diffie-hellman-group1-sha1" is used for the first > defined key exchange method using an Oakley group referenced from > [RFC2412]. The Working Group first attempted to progress the > namespace scheme by using "diffie-hellman-group2-sha1" for the second > defined key exchange (kex) name. This name was never used in any > Working Group documents but was discussed in the mailing list. It is > not known if this kex name was implemented in any shipping code. > During this deliberation period, the Working Group wanted to provide > for a better naming scheme and attempted to follow the numbering > scheme of group numbers from [RFC3526]. This resulted in the > selection of "diffie-hellman-group14-sha1" rather than > "diffie-hellman-group2-sha1" which the Working Group felt was not as > descriptive. After this name was generally approved by consensus and > started appearing in subsequent Internet Drafts (and shipping code), > it was noted that the numbers associated with the groups in [RFC3526] > were assigned by the IANA and may be changed in the future, or that > numbers may not be used at all. This caused some indecision within > the Working Group which was resolved at the Working Group meeting at > the 60th IETF with the formal adoption of the > "diffie-hellman-group14-sha1" name for the second defined kex method. > This inconsistency should not be repeated in the future. Future > groups borrowed from [RFC2412] or its successors should not attempt > to associate SSH kex algorithms with numbers from [RFC3526]. The > naming of future specifications of Diffie-Hellman kex methods using > Oakley groups defined in [RFC2412] or its successors should be > performed with forethought and care. It will probably be best if > future names are unique to SSH and not dependent upon any external > naming or numbering schemes. Authors of future kex proposals may > wish to consider the use of "diffie-hellman-group3-sha1" or > "diffie-hellman-group15-sha1" for the next name. I don't think this level of "legislative history" needs to be in the document; that is what we have mailing list archives for. I do not believe this document should make a value judgement on whether "it will probably be best if future names are unique to SSH", because I do not believe that we have consensus on whether that statement is true. When I started reading your message, I was going to avoid revisiting Tero's argument that numbers assigned in an IANA-managed registry are not stable. However, since you've included a statement to that effect in the text, I must point out that this also was a point of contention. It was not "pointed out" or "noted" that IANA was a bunch of morons who would randomly change the meaning of a protocol constant defined by IETF consensus. It was argued, and there was argument against this position. I'm sorry, but given that there was considerable argument over these issues and no clear resolution, I am opposed to any language in the draft which implies otherwise. An IETF standards-track document simply cannot say "the working group was unable to reach consensus, but it should be this way". Any statement made in such a document must be the _result_ of WG consensus. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 7 19:15:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18864 for ; Mon, 7 Feb 2005 19:15:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AB86C5218; Tue, 8 Feb 2005 00:15:25 +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 1488051D6 for ; Tue, 8 Feb 2005 00:15:24 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1CyJ2I-0007Nm-00; Tue, 08 Feb 2005 00:15:22 +0000 From: Ben Harris To: jhutz@cmu.edu Subject: Re: DH KEX names an "aberration"? In-Reply-To: <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Tue, 08 Feb 2005 00:15:22 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> you write: >I do not believe this document should make a value judgement on whether "it >will probably be best if future names are unique to SSH", because I do not >believe that we have consensus on whether that statement is true. I agree. To my mind, the naming of future KEX methods really isn't important, and certainly isn't worth an entire page of explanatory text. The names are opaque strings, and anyone wanting to know what one means will have to refer to the IANA registry anyway (since the two methods defined so far use different naming schemes), so the next one (if group exchange doesn't make it redundant) could perfectly well be called diffie-hellman-plippyploppycheesenose-sha1 without causing any problems. My feeling is that [SSH-TRANS] should be silent both on the history of the existing names and what names should be used in future. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 7 21:43:51 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01232 for ; Mon, 7 Feb 2005 21:43:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 856EF5191; Tue, 8 Feb 2005 02:43:45 +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 BF73E5171 for ; Tue, 8 Feb 2005 02:43:43 +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 j182gagx028410; Mon, 7 Feb 2005 18:42:37 -0800 (PST) Received: from thunk (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 j182gaQp028665; Mon, 7 Feb 2005 21:42:36 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j182gaId021976; Mon, 7 Feb 2005 21:42:36 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j182galv021975; Mon, 7 Feb 2005 21:42:36 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: DH KEX names an "aberration"? From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: Chris Lonvick , ietf-ssh@NetBSD.org In-Reply-To: <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1107830555.19442.245.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 07 Feb 2005 21:42:35 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-02-07 at 16:56, Jeffrey Hutzelman wrote: > I don't think this level of "legislative history" needs to be in the > document; that is what we have mailing list archives for. Agreed. > I do not believe this document should make a value judgement on whether "it > will probably be best if future names are unique to SSH", because I do not > believe that we have consensus on whether that statement is true. Also agreed. Let's not try to predict the future. > An IETF standards-track document simply cannot say "the > working group was unable to reach consensus, but it should be this way". When i took a straw poll, there was no clear consensus either way. Since this *should have been* a trivial matter, we had a public coin flip. we seem to have gotten lost inside the bikeshed (see http://www.unixguide.net/freebsd/faq/16.19.shtml). - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 8 00:27:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11636 for ; Tue, 8 Feb 2005 00:27:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5A60D51A0; Tue, 8 Feb 2005 05:27: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 961915171 for ; Tue, 8 Feb 2005 05:27:42 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA13109; Tue, 8 Feb 2005 00:27:41 -0500 (EST) From: der Mouse Message-Id: <200502080527.AAA13109@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, 8 Feb 2005 00:16:11 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? In-Reply-To: References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > [...], so the next [KEX method] (if group exchange doesn't make it > redundant) could perfectly well be called > diffie-hellman-plippyploppycheesenose-sha1 without causing any > problems. Well, except that some people would probably prefer diffie-hellman-eblisoshaughnessy-sha1. :-) Shall we toss a coin? /~\ 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 Feb 8 17:43:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09633 for ; Tue, 8 Feb 2005 17:43:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5930D52CB; Tue, 8 Feb 2005 22:43:06 +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 0EC0B52C6 for ; Tue, 8 Feb 2005 22:43:02 +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 j18Mh1gx023611 for ; Tue, 8 Feb 2005 14:43:01 -0800 (PST) Received: from thunk (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 j18Mh0Op006910; Tue, 8 Feb 2005 17:43:00 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j18Mh0If027377; Tue, 8 Feb 2005 17:43:00 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j18Mh0Ej027376; Tue, 8 Feb 2005 17:43:00 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: I've requested a timeslot for the next IETF. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107902578.25726.125.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 08 Feb 2005 17:42:59 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit FYI, I've requested a 1-hour timeslot for us at the next meeting in Minneapolis. Send any proposed agenda items to me. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 10 11:52:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15752 for ; Thu, 10 Feb 2005 11:52:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DB99052DC; Thu, 10 Feb 2005 16:52:16 +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 A3DC05178 for ; Thu, 10 Feb 2005 16:52:14 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2005 09:01:08 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1AGqCuC000952 for ; Thu, 10 Feb 2005 08:52:12 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA12189 for ; Thu, 10 Feb 2005 08:52:12 -0800 (PST) Date: Thu, 10 Feb 2005 08:52:12 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: RE: DH KEX names an "aberration"? In-Reply-To: <1107830555.19442.245.camel@thunk> Message-ID: References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> <1107830555.19442.245.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Mon, 7 Feb 2005, Bill Sommerfeld wrote: > On Mon, 2005-02-07 at 16:56, Jeffrey Hutzelman wrote: > > > I don't think this level of "legislative history" needs to be in the > > document; that is what we have mailing list archives for. > > Agreed. > > > I do not believe this document should make a value judgement on whether "it > > will probably be best if future names are unique to SSH", because I do not > > believe that we have consensus on whether that statement is true. > > Also agreed. Let's not try to predict the future. > > > An IETF standards-track document simply cannot say "the > > working group was unable to reach consensus, but it should be this way". > > When i took a straw poll, there was no clear consensus either way. Since this > *should have been* a trivial matter, we had a public coin flip. > > we seem to have gotten lost inside the bikeshed > (see http://www.unixguide.net/freebsd/faq/16.19.shtml). The prior text which seemed to have near consensus was: Additional methods may be defined as specified in [SSH-NUMBERS]. Note that for historical reasons the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. Future groups borrowed from [RFC2412] should not attemp to use the same numbering scheme used by [RFC3526], but should use numbering unique to SSH. I.e., the next group defined for SSH should be diffie-hellman-group2-sha1, regardless of it's source. From the comments it looks like we should remove the text about the history and the guidance for the future. As such we would then have: Additional methods may be defined as specified in [SSH-NUMBERS]. The name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. The Working Group followed the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. Future groups borrowed from [RFC2412] or its successors should not attemp to use the same numbering scheme used by [RFC3526]. Is this acceptable? I do want to say that the primary purpose of this is for [NUMBERS]; this is supposed to be the instructions for the IANA for the namespace. It's duplicated in [TRANS] for completeness. Since we're meeting in Minneapolis, I'd like to get the IDs resubmitted before the deadline which is 21 February. Can I get some feedback on this soon? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 10 12:11:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17423 for ; Thu, 10 Feb 2005 12:11:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 11CF85300; Thu, 10 Feb 2005 17:11:05 +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 2A2A552FE for ; Thu, 10 Feb 2005 17:11:01 +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 j1AHB0nK021100; Thu, 10 Feb 2005 10:11:00 -0700 (MST) Received: from thunk (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 j1AHAxQp029694; Thu, 10 Feb 2005 12:11:00 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1AHAxeh011411; Thu, 10 Feb 2005 12:10:59 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1AHAxAc011410; Thu, 10 Feb 2005 12:10:59 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: DH KEX names an "aberration"? From: Bill Sommerfeld To: Chris Lonvick Cc: ietf-ssh@NetBSD.org In-Reply-To: References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> <1107830555.19442.245.camel@thunk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1108055458.11303.10.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 10 Feb 2005 12:10:58 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit here's a revision which documents the past rather than constraining the future: Additional methods may be defined as specified in [SSH-NUMBERS]. The name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. SSH maintains its own group identifier space which is logically distinct from Oakley and IKE; however, for one additional group, the Working Group adopted the number assigned by [RFC3526], using diffie-hellman-group14-sha1 for the name of the second defined group. Implementations should treat these names as opaque identifiers and should not assume any relationship between the groups used by SSH and the groups defined in 2412 and its successors. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 10 13:04:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21832 for ; Thu, 10 Feb 2005 13:04:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A2CC2534D; Thu, 10 Feb 2005 18:04:18 +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 B81F35348 for ; Thu, 10 Feb 2005 18:04:13 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7125935; Thu, 10 Feb 2005 11:04:12 -0700 Message-ID: <420BA220.2070004@vandyke.com> Date: Thu, 10 Feb 2005 11:04:16 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> <69EACAED88E645DE657FEDED@SIRIUS.FAC.CS.CMU.EDU> <1107830555.19442.245.camel@thunk> <1108055458.11303.10.camel@thunk> In-Reply-To: <1108055458.11303.10.camel@thunk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > here's a revision which documents the past rather than constraining the future: > > Additional methods may be defined as specified in [SSH-NUMBERS]. The > name "diffie-hellman-group1-sha1" is used for a key exchange method > using an Oakley group as defined in [RFC2412]. SSH maintains its own > group identifier space which is logically distinct from Oakley and IKE; > however, for one additional group, the Working Group adopted the number > assigned by [RFC3526], using diffie-hellman-group14-sha1 for the name of > the second defined group. Implementations should treat these names as > opaque identifiers and should not assume any relationship between the groups > used by SSH and the groups defined in 2412 and its successors. This sounds good to me. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 11 08:50:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28390 for ; Fri, 11 Feb 2005 08:50:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1396653EA; Fri, 11 Feb 2005 13:49:55 +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 46CE651E2 for ; Fri, 11 Feb 2005 13:49:53 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1CzbBA-0000P3-00; Fri, 11 Feb 2005 13:49:52 +0000 From: Ben Harris To: sommerfeld@sun.com Subject: Re: DH KEX names an "aberration"? In-Reply-To: <1108055458.11303.10.camel@thunk> References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <1108055458.11303.10.camel@thunk> Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Fri, 11 Feb 2005 13:49:52 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1108055458.11303.10.camel@thunk> you write: >here's a revision which documents the past rather than constraining the future: > > Additional methods may be defined as specified in [SSH-NUMBERS]. The > name "diffie-hellman-group1-sha1" is used for a key exchange method > using an Oakley group as defined in [RFC2412]. SSH maintains its own > group identifier space which is logically distinct from Oakley and IKE; > however, for one additional group, the Working Group adopted the number > assigned by [RFC3526], using diffie-hellman-group14-sha1 for the name of > the second defined group. Implementations should treat these names as > opaque identifiers and should not assume any relationship between the groups > used by SSH and the groups defined in 2412 and its successors. That seems good to me. Having looked at the relevant RFCs and the IANA IPsec registry, it looks like the official reference for IPsec group 2 is RFC 2409 rather than RFC 2412, and RFC 3526 is only vaguely a successor to either. Perhaps "in 2412 and its successors" should read "for IKE". -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 14 10:06:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11286 for ; Mon, 14 Feb 2005 10:06:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 43A2B53D5; Mon, 14 Feb 2005 15:06:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 874A451FD for ; Mon, 14 Feb 2005 15:06:23 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 6C6191B803B; Mon, 14 Feb 2005 16:06:06 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 04352-02-28; Mon, 14 Feb 2005 16:05:56 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 282C81B801E; Mon, 14 Feb 2005 16:05:56 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1EF5tXa012741; Mon, 14 Feb 2005 16:05:55 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1EF5peQ012738; Mon, 14 Feb 2005 16:05:51 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Darren Tucker Cc: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 14 Feb 2005 16:05:50 +0100 In-Reply-To: <41FA6F3D.2040501@zip.com.au> Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Darren Tucker writes: > The things that aren't clear: > - how to listen on all IPv4 and IPv6 interfaces. > - how to listen on localhost only on IPv4 and IPv6 > > Working with Damien Miller, we've come up with the following > suggestions. After some digging, it turns out we're (belatedly) > seconding suggestions made by Niels Möller[1] in 2001! It seems I haven't changed my mind since back then ;-). I like your proposed text, with only one minor concern (see below). > (1) the string "" should specify that connections are allowed from anywhere > (2) "address to bind" should permit either a domain name or address > (3) the string "localhost" should have a special meaning to the server > of "all loopback IPv4 and IPv6 interfaces". > [proposed text] > The 'address to bind' and 'port number to bind' specify the IP address > or domain name and port to which the socket to be listened is bound. > The address should be "" if connections are to accepted from anywhere > on all supported protocol families. > > The server SHOULD treat an address of "localhost" to be a special case > meaning to listen on all supported protocol families on its loopback > interfaces only. > > The strings "0.0.0.0" and "::" should be used to listen on all > interfaces on only IPv4 or IPv6 respectively. Similarly, strings of > "127.0.0.1" or "::1" should be used to listen on the loopback > interface. > > Note that the client can still filter connections based on information > passed in the open request. > [/proposed text] I have some concern with the phrase "all supported protocol families". I don't think it is wise to interpret that as "all protocol families that getaddrinfo return". It should be IPv4, IPv6 and, beyond that, only protocol families that *really* make sense to implementor and/or local sysadm. One simple argument against random protocol families is that we don't specify what the "originator IP address" and "originator port" in SSH_MSG_CHANNEL_OPEN "forwarded-tcpip". Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 14 10:12:38 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12162 for ; Mon, 14 Feb 2005 10:12:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BC5DF53D7; Mon, 14 Feb 2005 15:12:32 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 8FAB951E5 for ; Mon, 14 Feb 2005 15:12:30 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id E91341B801E; Mon, 14 Feb 2005 16:12:28 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 16159-01-29; Mon, 14 Feb 2005 16:12:18 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id C40341B801B; Mon, 14 Feb 2005 16:12:18 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1EFCIXa012814; Mon, 14 Feb 2005 16:12:18 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1EFCFTP012811; Mon, 14 Feb 2005 16:12:15 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <15C963F352197EFA4B5DD480@SIRIUS.FAC.CS.CMU.EDU> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 14 Feb 2005 16:12:15 +0100 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > I'll take input on the following which may modify this text: > > - Did anyone actually use "diffie-hellman-group2-sha1" in shipping code? Shipped versions of lsh have used "diffie-hellman-group2-sha1" and "diffie-hellman-group14-sha1" as synonyms. > - Should we state that "2" has been poisoned because of that? No. > - Should we leave it as use "3" or "15" next? (If anyone responds with > "no" then they'll have to propose something better.) I think it's best to not try to make promises on behalf of the future working group. Bill's neutral text looked good to me. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 14 10:32:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14366 for ; Mon, 14 Feb 2005 10:32:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 595A952CB; Mon, 14 Feb 2005 15:32:09 +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 C37A951E5 for ; Mon, 14 Feb 2005 15:32:04 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2005 07:41:45 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1EFW2uC010528 for ; Mon, 14 Feb 2005 07:32:02 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA07277 for ; Mon, 14 Feb 2005 07:32:02 -0800 (PST) Date: Mon, 14 Feb 2005 07:32:02 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: DH KEX names an "aberration"? In-Reply-To: Message-ID: References: <000001c50ae9$96dd7240$d7b7fea9@nucleus> <1108055458.11303.10.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Fri, 11 Feb 2005, Ben Harris wrote: > In article <1108055458.11303.10.camel@thunk> you write: > >here's a revision which documents the past rather than constraining the future: > > > > Additional methods may be defined as specified in [SSH-NUMBERS]. The > > name "diffie-hellman-group1-sha1" is used for a key exchange method > > using an Oakley group as defined in [RFC2412]. SSH maintains its own > > group identifier space which is logically distinct from Oakley and IKE; > > however, for one additional group, the Working Group adopted the number > > assigned by [RFC3526], using diffie-hellman-group14-sha1 for the name of > > the second defined group. Implementations should treat these names as > > opaque identifiers and should not assume any relationship between the groups > > used by SSH and the groups defined in 2412 and its successors. > > That seems good to me. Having looked at the relevant RFCs and the IANA > IPsec registry, it looks like the official reference for IPsec group 2 is > RFC 2409 rather than RFC 2412, and RFC 3526 is only vaguely a successor to > either. Perhaps "in 2412 and its successors" should read "for IKE". Ben points out something important. 2412 is INFORMATIONAL. 2409 and 3526 are STANDARDS TRACK. Since the proposed text appears to have general consensus, I'll modify the referents as follows: Additional methods may be defined as specified in [SSH-NUMBERS]. The name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2409]. SSH maintains its own group identifier space which is logically distinct from Oakley [RFC2412] and IKE; however, for one additional group, the Working Group adopted the number assigned by [RFC3526], using diffie-hellman-group14-sha1 for the name of the second defined group. Implementations should treat these names as opaque identifiers and should not assume any relationship between the groups used by SSH and the groups defined for IKE. 2409 and 3526 will be normative references and 2412 will be informational. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 14 11:55:42 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21443 for ; Mon, 14 Feb 2005 11:55:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6033D5401; Mon, 14 Feb 2005 16:55:30 +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 39C6851DD for ; Mon, 14 Feb 2005 16:55:28 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA05360; Mon, 14 Feb 2005 11:55:27 -0500 (EST) From: der Mouse Message-Id: <200502141655.LAA05360@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, 14 Feb 2005 11:44:49 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> [connection forwarding stuff] > I have some concern with the phrase "all supported protocol > families". I don't think it is wise to interpret that as "all > protocol families that getaddrinfo return". It should be IPv4, IPv6 > and, beyond that, only protocol families that *really* make sense to > implementor and/or local sysadm. Consider, for example, a dual-stack IP-and-DECnet machine. > One simple argument against random protocol families is that we don't > specify what the "originator IP address" and "originator port" in > SSH_MSG_CHANNEL_OPEN "forwarded-tcpip". This sentence is incomplete; there appears to be a verb missing. This too has always struck me as a problem with ssh: it is rather thoroughly IP-centric, whereas there is no inherent reason it couldn't be designed so as to be usable over any reliable octet stream (DECnet is my usual gedanken example). For example, consider agent forwarding and port forwarding; both are specified in a way which is impossible to extend to, say, DECnet, since they do not have any kind of protocol identifier. You'd have to design a parallel set of requests to do the analogous things with some other protocol. (Putting "tcpip" in the names of the port-forwarding messages helps make this obvious for that one, but the forwarding-notice message really needs a redesign.) /~\ 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 Feb 14 13:40:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00996 for ; Mon, 14 Feb 2005 13:40:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3E2CC51DB; Mon, 14 Feb 2005 18:40:26 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from liandra.pc.cs.cmu.edu (dsl093-061-085.pit1.dsl.speakeasy.net [66.93.61.85]) by mail.netbsd.org (Postfix) with SMTP id 856235189 for ; Mon, 14 Feb 2005 18:40:24 +0000 (UTC) Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa32102; 14 Feb 2005 13:38 EST Date: Mon, 14 Feb 2005 13:38:08 -0500 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses Message-ID: <36030000.1108406288@liandra.pc.cs.cmu.edu> In-Reply-To: <200502141655.LAA05360@Sparkle.Rodents.Montreal.QC.CA> References: <41FA6F3D.2040501@zip.com.au> <200502141655.LAA05360@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, February 14, 2005 11:44:49 -0500 der Mouse wrote: > This too has always struck me as a problem with ssh: it is rather > thoroughly IP-centric, whereas there is no inherent reason it couldn't > be designed so as to be usable over any reliable octet stream (DECnet > is my usual gedanken example). There is only one Internet Protocol. This design philosophy is a fundamental part of the internet architecture. -- 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 Mon Feb 14 14:07:54 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03164 for ; Mon, 14 Feb 2005 14:07:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 85E53543B; Mon, 14 Feb 2005 19:07:49 +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 49E725164 for ; Mon, 14 Feb 2005 19:07:47 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA06187; Mon, 14 Feb 2005 14:07:46 -0500 (EST) From: der Mouse Message-Id: <200502141907.OAA06187@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, 14 Feb 2005 13:49:39 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: <36030000.1108406288@liandra.pc.cs.cmu.edu> References: <41FA6F3D.2040501@zip.com.au> <200502141655.LAA05360@Sparkle.Rodents.Montreal.QC.CA> <36030000.1108406288@liandra.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> This too has always struck me as a problem with ssh: it is rather >> thoroughly IP-centric, [...] > There is only one Internet Protocol. Must be nice to be able to live in such a blinkered environment. I use two different ones fairly commonly even today (IPv4 and IPv6), and once upon a time used another (DECnet) not uncommonly, though it's been some years since I had much to do with it. I suppose you will try to finesse this by defining "Internet Protocol" suitably. Go ahead; it doesn't bother me what kind of blinkers you want to wear - I'm not interested in wearing them. > This design philosophy is a fundamental part of the internet > architecture. Tell that to X11, which supported non-IP connections (FamilyDECnet, FamilyChaos) before IPv6 even existed. I see no reason why every - or indeed any - protocol design has to buy into this "today's IP is the One True Way" philosophy. Fortunately ssh is designed well enough that it won't be that difficult. Port forwarding just needs a parallel set of messages designed to replace the *tcpip* ones. Agent forwarding needs to grab a message number to replace FORWARDING_NOTICE. Nothing too demanding. /~\ 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 Feb 14 18:08:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00084 for ; Mon, 14 Feb 2005 18:08:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 19E685314; Mon, 14 Feb 2005 23:08:22 +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 1F120524E for ; Mon, 14 Feb 2005 23:08:18 +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 j1EN8Egx005925; Mon, 14 Feb 2005 15:08:14 -0800 (PST) Received: from thunk (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 j1EN8EQp027365; Mon, 14 Feb 2005 18:08:14 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1EN8EvE017697; Mon, 14 Feb 2005 18:08:14 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1EN8DkJ017696; Mon, 14 Feb 2005 18:08:13 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: tcpip-forward requests and bind addresses From: Bill Sommerfeld To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Darren Tucker , ietf-ssh@NetBSD.org In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <1108422492.13183.233.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 14 Feb 2005 18:08:13 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-14 at 10:05, Niels M=F6ller wrote: > I have some concern with the phrase "all supported protocol families". > I don't think it is wise to interpret that as "all protocol families > that getaddrinfo return". It should be IPv4, IPv6 and, beyond that, > only protocol families that *really* make sense to implementor and/or > local sysadm. Agreed. > One simple argument against random protocol families is that we don't > specify what the "originator IP address" and "originator port" in > SSH_MSG_CHANNEL_OPEN "forwarded-tcpip". There exist protocols which use the IP addressing model but not ip wire=20 encoding. These protocols tend to be problematic administratively but they clearly *could* be included in a wildcard bind. Given that you can use this option to tunnel between addressing universes we're already stuck with essentially implementation-defined behavior=20 from the receiver.. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 14 18:26:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02272 for ; Mon, 14 Feb 2005 18:26:44 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AF1725192; Mon, 14 Feb 2005 23:26:41 +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 BCD9C5164 for ; Mon, 14 Feb 2005 23:26:39 +0000 (UTC) Received: from dodgynet.dyndns.org (203-217-74-226.dyn.iinet.net.au [203.217.74.226]) (authenticated bits=0) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1ENQPA6018023; Tue, 15 Feb 2005 10:26:25 +1100 Received: from [127.0.0.1] (gate.dodgy.net.au [192.168.32.1]) by dodgynet.dyndns.org (8.13.1/8.12.8) with ESMTP id j1ENQO2f023162; Tue, 15 Feb 2005 10:26:25 +1100 Message-ID: <421133B1.8080408@zip.com.au> Date: Tue, 15 Feb 2005 10:26:41 +1100 From: Darren Tucker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > I have some concern with the phrase "all supported protocol families". > I don't think it is wise to interpret that as "all protocol families > that getaddrinfo return". It should be IPv4, IPv6 and, beyond that, > only protocol families that *really* make sense to implementor and/or > local sysadm. I meant "all protocol families supported by the SSH implementation" not "all protocol families supported by the platform". For most current implementations that would probably be IPv4 or IPv4+IPv6 but there could be others if the implementation supports them. -- 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 Tue Feb 15 07:48:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26338 for ; Tue, 15 Feb 2005 07:48:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7F16B54E3; Tue, 15 Feb 2005 12:48:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from draco.cus.cam.ac.uk (draco.cus.cam.ac.uk [131.111.8.18]) by mail.netbsd.org (Postfix) with ESMTP id 0906C5168 for ; Tue, 15 Feb 2005 12:48:18 +0000 (UTC) Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.47) id 1D127l-0005DF-41 for ietf-ssh@netbsd.org; Tue, 15 Feb 2005 12:48:17 +0000 Date: Tue, 15 Feb 2005 12:48:17 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: subsystem name registry not mentioned in [SSH-NUMBERS] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list While connect-23 says that "Subsystem names follow the DNS extensibility naming convention outlined in [SSH-NUMBERS]," it doesn't explicitly state that non-DNS-derived names are to be assigned by IANA, and more importantly, assignednumbers-10 doesn't instruct IANA to create a registry for subsystem names. I'd propose that an additional section be added to [SSH-NUMBERS] after 4.9.4 reading: 4.9.5 Connection Protocol Subsystem Names There are no initial assignments of Connection Protocol Subsystem Names. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 15 10:05:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08111 for ; Tue, 15 Feb 2005 10:05:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E187F5270; Tue, 15 Feb 2005 15:04:55 +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 AE187523C for ; Tue, 15 Feb 2005 15:04:53 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2005 07:14:53 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107763200"; d="scan'208"; a="614546760:sNHT295612604" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1FF3Iq8001705 for ; Tue, 15 Feb 2005 07:03:18 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA16188 for ; Tue, 15 Feb 2005 07:03:21 -0800 (PST) Date: Tue, 15 Feb 2005 07:03:21 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: <421133B1.8080408@zip.com.au> Message-ID: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Current text in [CONNECT]-23 Section 7.1: The 'address to bind' and 'port number to bind' specify the IP address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. (Note that the client can still filter connections based on information passed in the open request.) I took Darren's original proposal, merged in the responses and made an attempt at reorganizing it. [new proposed text] The 'address to bind' and 'port number to bind' specify the IP address or domain name and port to which the socket to be listened is bound. The address SHOULD be "" if connections are to accepted from anywhere on all protocol families supported by the SSH implementation. The strings "0.0.0.0" and "::" SHOULD be used to listen on all interfaces on only IPv4 or IPv6 respectively. The server SHOULD treat an 'address to bind' of "localhost" to be a special case meaning to listen on all supported protocol families on its loopback interfaces only. Similarly, the numerically assigned loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] SHOULD be used to listen on the loopback interface with only IPv4 or IPv6 respectively. Note that the client can still filter connections based on information passed in the open request. [/new proposed text] Please review this. I've changed some "should"s to "SHOULD"s (should any of these be left as "should"s or changed to "MUST"s?) and have added the references of RFC3330 and RFC3515 to the loopback addresses. I'd like to get an okee-dokee on this rsn so I can submit the IDs before the cutoff date. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 15 12:55:38 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27627 for ; Tue, 15 Feb 2005 12:55:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 64EAB5551; Tue, 15 Feb 2005 17:55:18 +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 528A8554E for ; Tue, 15 Feb 2005 17:55:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA22837; Tue, 15 Feb 2005 12:55:14 -0500 (EST) From: der Mouse Message-Id: <200502151755.MAA22837@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, 15 Feb 2005 12:45:39 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > [new proposed text] [edited down -dM] > The address SHOULD be "" if connections are to accepted from anywhere > on all protocol families supported by the SSH implementation. The > strings "0.0.0.0" and "::" SHOULD be used to listen on all interfaces > on only IPv4 or IPv6 respectively. I think SHOULD is the wrong word to use here. What we are doing is saying "as a special case, this string is defined to have this semantic". This is not a SHOULD any more than any of the other defined semantics is. The whole document is implicitly covered by an "implementations SHOULD implement these esmantics", after all. > The server SHOULD treat an 'address to bind' of "localhost" to be a > special case meaning to listen on all supported protocol families on > its loopback interfaces only. Similarly, the numerically assigned > loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] SHOULD be > used to listen on the loopback interface with only IPv4 or IPv6 > respectively. Here, the first SHOULD at least makes sense, though what it's really doing is to define yet another special-case semantic. The second one here is in the same situation as the SHOULDs of the other paragraph above. I don't think the SHOULD/MUST/MAY language is appropriate here. I'd word this something like Some strings have special-case semantics: "" as an address to bind means that connections are to be accepted from anywhere on all protocol families supported by the SSH implementation. "0.0.0.0" means to listen on all IPv4 addresses [note: not "interfaces"; the mapping between intefaces and addresses can be multi-valued in either direction]. "::" means to listen on all IPv6 addresses. "localhost" means to listen on all supported protocol families on loopback addresses only. "127.0.0.1" and "::1", while not really special cases for a normally configured system [RFC3330] [RFC3515], indicate listening on the loopback interfaces for IPv4 and IPv6 respectively. /~\ 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 Feb 15 14:36:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27018 for ; Tue, 15 Feb 2005 14:36:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5B474555E; Tue, 15 Feb 2005 19:35:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 4489151E8 for ; Tue, 15 Feb 2005 19:35:54 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 9ADC81B802D; Tue, 15 Feb 2005 20:35:37 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 27898-03-13; Tue, 15 Feb 2005 20:35:25 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id AC7F81B8019; Tue, 15 Feb 2005 20:35:25 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1FJZPXa028396; Tue, 15 Feb 2005 20:35:25 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1FJZLDj028393; Tue, 15 Feb 2005 20:35:21 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: subsystem name registry not mentioned in [SSH-NUMBERS] References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 15 Feb 2005 20:35:20 +0100 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Ben Harris writes: > 4.9.5 Connection Protocol Subsystem Names > > There are no initial assignments of Connection Protocol Subsystem > Names. As far as I'm aware, there's one deployed subsystem name: "sftp". But perhaps this isn't the right place to specify that? (I'm afraid I lost track of sftp after the sftp/file-xfer/version exchange discussion some months ago). Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 15 14:38:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27694 for ; Tue, 15 Feb 2005 14:38:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 16BE65568; Tue, 15 Feb 2005 19:38:40 +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 0943E527C for ; Tue, 15 Feb 2005 19:38:37 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7141903; Tue, 15 Feb 2005 12:38:37 -0700 Message-ID: <42124FBE.1040505@vandyke.com> Date: Tue, 15 Feb 2005 12:38:38 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: subsystem name registry not mentioned in [SSH-NUMBERS] References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Ben Harris writes: > > >>4.9.5 Connection Protocol Subsystem Names >> >> There are no initial assignments of Connection Protocol Subsystem >> Names. > > > As far as I'm aware, there's one deployed subsystem name: "sftp". But > perhaps this isn't the right place to specify that? (I'm afraid I lost > track of sftp after the sftp/file-xfer/version exchange discussion > some months ago). It is coming :-) But slowly :-( I believe that the registry can be created empty and SFTP will ammend it. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 15 18:26:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27660 for ; Tue, 15 Feb 2005 18:26:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BE69554F4; Tue, 15 Feb 2005 23:25:43 +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 0A3FB51A6 for ; Tue, 15 Feb 2005 23:25:40 +0000 (UTC) Received: from dodgynet.dyndns.org (203-217-74-226.dyn.iinet.net.au [203.217.74.226]) (authenticated bits=0) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1FNPcA6019169; Wed, 16 Feb 2005 10:25:38 +1100 Received: from [127.0.0.1] (gate.dodgy.net.au [192.168.32.1]) by dodgynet.dyndns.org (8.13.1/8.12.8) with ESMTP id j1FNPVmR022150; Wed, 16 Feb 2005 10:25:35 +1100 Message-ID: <421284F1.3010208@zip.com.au> Date: Wed, 16 Feb 2005 10:25:37 +1100 From: Darren Tucker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: >> The server SHOULD treat an 'address to bind' of "localhost" to be a >> special case meaning to listen on all supported protocol families on >> its loopback interfaces only. [...] > Here, the first SHOULD at least makes sense, though what it's really > doing is to define yet another special-case semantic. The reason I said "SHOULD" is that some APIs have a guaranteed way of getting a loopback-only bind and I thought that would be preferable if available. There may, however be a good reason for an implementation to rely on the name service for this, hence "SHOULD". If the consensus is it's uncecessary it could be dropped and left as an implementation detail. > I don't think the SHOULD/MUST/MAY language is appropriate here. I'd > word this something like > > Some strings have special-case semantics: "" as an address to bind "is an address" ? > means that connections are to be accepted from anywhere on all > protocol families supported by the SSH implementation. "0.0.0.0" > means to listen on all IPv4 addresses > [note: not "interfaces"; the > mapping between intefaces and addresses can be multi-valued in > either direction]. That's a good point. > "::" means to listen on all IPv6 addresses. > "localhost" means to listen on all supported protocol families on > loopback addresses only. "listen on all protocol families supported by the SSH implementation .." ? > "127.0.0.1" and "::1", while not really > special cases for a normally configured system [RFC3330] [RFC3515], Is RFC3515 a typo? > indicate listening on the loopback interfaces for IPv4 and IPv6 > respectively. -- 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 Feb 16 00:11:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19440 for ; Wed, 16 Feb 2005 00:11:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B719D521B; Wed, 16 Feb 2005 05:11: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 89A89515B for ; Wed, 16 Feb 2005 05:11:37 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA06463; Wed, 16 Feb 2005 00:11:31 -0500 (EST) From: der Mouse Message-Id: <200502160511.AAA06463@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, 16 Feb 2005 00:04:51 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: <421284F1.3010208@zip.com.au> References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> I don't think the SHOULD/MUST/MAY language is appropriate here. I'd >> word this something like >> Some strings have special-case semantics: "" as an address to bind > "is an address" ? No. Try reading it as "" as an address-to-bind parameter means that... If you think the sense is OK but the wording can be improved, fine; I'm not wedded to the wording, and the clearest wording we can find will be none too clear for some of the people this needs to reach. >> "localhost" means to listen on all supported protocol families >> on loopback addresses only. > "listen on all protocol families supported by the SSH implementation > .." ? If you prefer; that's what "supported protocol families" really means here anyway, and if anyone sees increased value in the wordier version, I'm not going to kick about it. >> "127.0.0.1" and "::1", while not really special cases for a >> normally configured system [RFC3330] [RFC3515], > Is RFC3515 a typo? Looks like it, but not on my part. The text I was basing that on was loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] ... which I (then) didn't bother sanity-checking. I have now checked; 3515 is clearly not the right RFC, and I don't know offhand what is. /~\ 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 Feb 16 02:51:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07679 for ; Wed, 16 Feb 2005 02:51:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D7DA3559F; Wed, 16 Feb 2005 07:51:45 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 4A58F515B for ; Wed, 16 Feb 2005 07:51:43 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 312CD1B8049; Wed, 16 Feb 2005 08:51:24 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 06532-02-28; Wed, 16 Feb 2005 08:51:15 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 210D61B8015; Wed, 16 Feb 2005 08:51:15 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1G7pEXa013374; Wed, 16 Feb 2005 08:51:14 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1G7p8qT013371; Wed, 16 Feb 2005 08:51:08 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 16 Feb 2005 08:51:07 +0100 In-Reply-To: <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > Looks like it, but not on my part. The text I was basing that on was > > loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] ... > > which I (then) didn't bother sanity-checking. I have now checked; 3515 > is clearly not the right RFC, and I don't know offhand what is. I think it should be RFC 3513, "Internet Protocol Version 6 (IPv6) Addressing Architecture". Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 16 07:26:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01689 for ; Wed, 16 Feb 2005 07:26:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 54C99561D; Wed, 16 Feb 2005 12:26:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mail.netbsd.org (Postfix) with ESMTP id 717FB5259 for ; Wed, 16 Feb 2005 12:26:22 +0000 (UTC) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2005 07:25:19 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GCPDhF026305; Wed, 16 Feb 2005 07:25:14 -0500 (EST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA01183; Wed, 16 Feb 2005 04:25:12 -0800 (PST) Date: Wed, 16 Feb 2005 04:25:12 -0800 (PST) From: Chris Lonvick To: =?iso-8859-1?q?Niels_M=F6ller?= Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: Message-ID: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, On Tue, 16 Feb 2005, [iso-8859-1] Niels M=F6ller wrote: > der Mouse writes: > > > Looks like it, but not on my part. The text I was basing that on was > > > > loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] ... > > > > which I (then) didn't bother sanity-checking. I have now checked; 3515 > > is clearly not the right RFC, and I don't know offhand what is. > > I think it should be RFC 3513, "Internet Protocol Version 6 (IPv6) > Addressing Architecture". Yup. My bad; fat fingers. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 16 08:51:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09781 for ; Wed, 16 Feb 2005 08:51:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 65929562F; Wed, 16 Feb 2005 13:51:09 +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 97D2A563D for ; Wed, 16 Feb 2005 13:51:04 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2005 06:01:08 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GDoxq8028371 for ; Wed, 16 Feb 2005 05:50:59 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA17170 for ; Wed, 16 Feb 2005 05:51:02 -0800 (PST) Date: Wed, 16 Feb 2005 05:51:02 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: Message-ID: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, How about the following which separates the thoughts into a list. --- The 'address to bind' and 'port number to bind' specify the IP address or domain name and port to which the socket to be listened is bound. Some strings used for the 'address to bind' have special-case semantics. "" means that connections are to be accepted from anywhere on all protocol families supported by the SSH implementation. "0.0.0.0" means to listen on all IPv4 addresses. Note: not "interfaces"; the mapping between intefaces and addresses can be multi-valued in either direction. "::" means to listen on all IPv6 addresses. "localhost" means to listen on all protocol families supported by the SSH implementation on loopback addresses only. Note: loopback addresses are defined in [RFC3330] for IPv4 and [RFC3513] for IPv6. "127.0.0.1" and "::1", while not really special cases for a normally configured system indicate listening on the loopback interfaces for IPv4 and IPv6 respectively. Note that the client can still filter connections based on information passed in the open request. --- Comments? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 16 09:20:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12906 for ; Wed, 16 Feb 2005 09:20:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8F66B5646; Wed, 16 Feb 2005 14:20:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 30501562B for ; Wed, 16 Feb 2005 14:20:18 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 55EEA1B8066; Wed, 16 Feb 2005 15:20:11 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 28585-01-14; Wed, 16 Feb 2005 15:20:00 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 31D101B806E; Wed, 16 Feb 2005 15:20:00 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1GEJxXa017542; Wed, 16 Feb 2005 15:19:59 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1GEJt70017539; Wed, 16 Feb 2005 15:19:55 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 16 Feb 2005 15:19:54 +0100 In-Reply-To: Message-ID: Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > How about the following which separates the thoughts into a list. The organization is clear, but it can be cut down a little. > The 'address to bind' and 'port number to bind' specify the IP address > or domain name and port to which the socket to be listened is bound. > Some strings used for the 'address to bind' have special-case > semantics. > > "" means that connections are to be accepted from anywhere on all > protocol families supported by the SSH implementation. Perhaps strike "from anywhere", the mechanism is not (on the surface) about restricting *from where* connections are accepted, only *to which* addresses. > "0.0.0.0" means to listen on all IPv4 addresses. Note: not > "interfaces"; the mapping between intefaces and addresses can be > multi-valued in either direction. Delete "Note: ...". It's important that we choose the right word, but the spec is not the right place to explain our choice in detail. > "::" means to listen on all IPv6 addresses. > > "localhost" means to listen on all protocol families supported by > the SSH implementation on loopback addresses only. Note: loopback > addresses are defined in [RFC3330] for IPv4 and [RFC3513] for > IPv6. I think "... loopback addresses only [RFC3330, RFC3513]." is sufficient reference. No other references in the text are introduced with a "Note:". > "127.0.0.1" and "::1", while not really special cases for a > normally configured system indicate listening on the loopback > interfaces for IPv4 and IPv6 respectively. The "not really special" applies to "0.0.0.0" and "::" as well. Cut it down to "127.0.0.1" and "::1" indicate listening on the loopback interfaces for IPv4 and IPv6 respectively. I don't think we need to comment on which of the strings are "special" and which are "normal", but if we want to do that, it should go into the first paragraph. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 16 12:54:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06823 for ; Wed, 16 Feb 2005 12:54:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AA9E0567A; Wed, 16 Feb 2005 17:54:20 +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 B2B7551E2 for ; Wed, 16 Feb 2005 17:54:18 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA09521; Wed, 16 Feb 2005 12:54:13 -0500 (EST) From: der Mouse Message-Id: <200502161754.MAA09521@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, 16 Feb 2005 12:46:51 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> "0.0.0.0" means to listen on all IPv4 addresses. Note: not >> "interfaces"; the mapping between intefaces and addresses can >> be multi-valued in either direction. > Delete "Note: ...". Yeah. I put that note in [brackets] when I wrote it because it was intended for the list (to explain why I switched from "interfaces" to "addresses"), not for the document. /~\ 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 Feb 16 16:42:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29550 for ; Wed, 16 Feb 2005 16:42:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BCC865236; Wed, 16 Feb 2005 21:42:38 +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 315935176 for ; Wed, 16 Feb 2005 21:42:37 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7144937 for ietf-ssh@netbsd.org; Wed, 16 Feb 2005 14:42:34 -0700 Message-ID: <4213BE4D.7090007@vandyke.com> Date: Wed, 16 Feb 2005 14:42:37 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Session channel extension to specify home directory? X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 We just had a user request us to start a shell session for them in an arbitrary directory. I was wondering what people would think of the following extension (for the session channel only): byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "home-directory" boolean want reply string path to use as home directory [UTF-8] What do you think? Are there security implications? Is it a bad idea? Would people implement this in their servers? (It definetly does not go in the connection draft at this late date-- perhaps it's own document or perhaps another document for extensions to the session channel.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 16 17:29:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04673 for ; Wed, 16 Feb 2005 17:29:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2C50E51F2; Wed, 16 Feb 2005 22:29:22 +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 4F25B51CC for ; Wed, 16 Feb 2005 22:29:20 +0000 (UTC) Received: from dodgynet.dyndns.org (203-217-74-226.dyn.iinet.net.au [203.217.74.226]) (authenticated bits=0) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1GMTHA6029342; Thu, 17 Feb 2005 09:29:17 +1100 Received: from [127.0.0.1] (gate.dodgy.net.au [192.168.32.1]) by dodgynet.dyndns.org (8.13.1/8.12.8) with ESMTP id j1GMTFT8003166; Thu, 17 Feb 2005 09:29:17 +1100 Message-ID: <4213C945.5010807@zip.com.au> Date: Thu, 17 Feb 2005 09:29:25 +1100 From: Darren Tucker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Session channel extension to specify home directory? References: <4213BE4D.7090007@vandyke.com> In-Reply-To: <4213BE4D.7090007@vandyke.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > We just had a user request us to start a shell session > for them in an arbitrary directory. [...] > Are there security implications? Is it a bad idea? Well, for one thing it would let users with restricted shells change directories. What value does it give beyond "(cd /some/path && some command)" ? -- 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 Feb 16 17:45:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05937 for ; Wed, 16 Feb 2005 17:45:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 51BBD5258; Wed, 16 Feb 2005 22:45:14 +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 906D551E6 for ; Wed, 16 Feb 2005 22:45:12 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7145201; Wed, 16 Feb 2005 15:45:11 -0700 Message-ID: <4213CCF9.4070405@vandyke.com> Date: Wed, 16 Feb 2005 15:45:13 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Tucker Cc: ietf-ssh@NetBSD.org Subject: Re: Session channel extension to specify home directory? References: <4213BE4D.7090007@vandyke.com> <4213C945.5010807@zip.com.au> In-Reply-To: <4213C945.5010807@zip.com.au> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Darren Tucker wrote: > Joseph Galbraith wrote: > >> We just had a user request us to start a shell session >> for them in an arbitrary directory. > > [...] > >> Are there security implications? Is it a bad idea? > > Well, for one thing it would let users with restricted shells change > directories. Argh... and the server has no way of knowing that x is a restricted shell and disallowing the command does it? > What value does it give beyond "(cd /some/path && some command)" ? It works with a NT server. This might be able to be worked around by sending cd /some/path\n as artifical user input before giving control to the user. But... it works with a VMS server (cd is written set default disk:[some.path]) But regardless, I don't think it is likely to get many supporters given the issue with restricted shells. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 06:43:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12176 for ; Thu, 17 Feb 2005 06:43:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B86B6516A; Thu, 17 Feb 2005 11:43:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id D4B71516A for ; Thu, 17 Feb 2005 11:43:19 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id E10901B802B; Thu, 17 Feb 2005 12:43:02 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 01489-01-30; Thu, 17 Feb 2005 12:42:50 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 9FBA21B8040; Thu, 17 Feb 2005 12:42:50 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1HBgoXa004254; Thu, 17 Feb 2005 12:42:50 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1HBgiTE004251; Thu, 17 Feb 2005 12:42:44 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Session channel extension to specify home directory? References: <4213BE4D.7090007@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 17 Feb 2005 12:42:44 +0100 In-Reply-To: <4213BE4D.7090007@vandyke.com> Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > We just had a user request us to start a shell session > for them in an arbitrary directory. Why not just use byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "env" boolean want reply string "HOME" string path to use as home directory to set the home directory to what you want. You still need to hack your server to let the provided value override value stored in the user database, but you don't need any protocol changes. > string path to use as home directory [UTF-8] As for character sets for file names, I would really hope that we can pass that can of worms over to other protocols, like sftp. > Would people implement this in their servers? Probably not. But it's at least reasonable for a client to have a user interface that lets the user attempt to set arbitrary environment variables using SSH_MSG_CHANNEL_REQUEST "env". And reasonable for a server to have a configurable list of environmant variables that clients are allowed to change. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 08:23:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20413 for ; Thu, 17 Feb 2005 08:23:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3D6D851E1; Thu, 17 Feb 2005 13:22:55 +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 F01F3516A for ; Thu, 17 Feb 2005 13:22:52 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2005 05:33:08 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1HDMkq8029622 for ; Thu, 17 Feb 2005 05:22:47 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA27001 for ; Thu, 17 Feb 2005 05:22:50 -0800 (PST) Date: Thu, 17 Feb 2005 05:22:50 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: Message-ID: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I appreciate the quick reviews and suggestions. If I don't hear any disagreement on this proposal within ~24 hours, I'll use it and submit the updated IDs to the repository. === The 'address to bind' and 'port number to bind' specify the IP address or domain name and port to which the socket to be listened is bound. Some strings used for the 'address to bind' have special-case semantics. "" means that connections are to be accepted on all protocol families supported by the SSH implementation. "0.0.0.0" means to listen on all IPv4 addresses. "::" means to listen on all IPv6 addresses. "localhost" means to listen on all protocol families supported by the SSH implementation on loopback addresses only, [RFC3330] and [RFC3513]. "127.0.0.1" and "::1" indicate listening on the loopback interfaces for IPv4 and IPv6 respectively. Note that the client can still filter connections based on information passed in the open request. === Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 08:31:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21222 for ; Thu, 17 Feb 2005 08:31:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B98285228; Thu, 17 Feb 2005 13:31:34 +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 8E087516A for ; Thu, 17 Feb 2005 13:31:31 +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 j1HDVUnK009763; Thu, 17 Feb 2005 06:31:30 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j1HDVTOp021272; Thu, 17 Feb 2005 08:31:30 -0500 (EST) Subject: Re: Session channel extension to specify home directory? From: Bill Sommerfeld To: Joseph Galbraith Cc: "ietf-ssh@netbsd.org" In-Reply-To: <4213BE4D.7090007@vandyke.com> References: <4213BE4D.7090007@vandyke.com> Content-Type: text/plain Message-Id: <1108647034.51832.1088.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 17 Feb 2005 08:30:35 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-02-16 at 16:42, Joseph Galbraith wrote: > We just had a user request us to start a shell session > for them in an arbitrary directory. > > I was wondering what people would think of the following > extension (for the session channel only): > > byte SSH_MSG_CHANNEL_REQUEST > uint32 recipient channel > string "home-directory" > boolean want reply > string path to use as home directory [UTF-8] starting the session in an arbitrary directory does not to me imply setting $HOME. clearly: 1) reading authorization information (~/.ssh/authorized_keys or ~/.*hosts) from a client-specified directory is an incredibly bad idea. I hope nobody's suggesting that but I run into bad ideas like this often enough that I feel compelled to point it out... 2) setting $HOME after authentication could be accomplished by the env request Niels mentioned. 3) setting the working directory to something other than $HOME could be accomplished in most shells by sending over a compound command. if the account's shell is not a normal shell, you can't do that -- but in that case the account is may also be a captive environment, where setting either of the working directory or $HOME might violate the assumption of that captive environment. > What do you think? Needs a few rounds of "what do you really want to do?" with your users. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 11:13:51 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13514 for ; Thu, 17 Feb 2005 11:13:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 00818519E; Thu, 17 Feb 2005 16:13:43 +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 B1AA0516A for ; Thu, 17 Feb 2005 16:13:41 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7146802; Thu, 17 Feb 2005 09:13:40 -0700 Message-ID: <4214C2B7.9090507@vandyke.com> Date: Thu, 17 Feb 2005 09:13:43 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: "ietf-ssh@netbsd.org" Subject: Re: Session channel extension to specify home directory? References: <4213BE4D.7090007@vandyke.com> <1108647034.51832.1088.camel@unknown.hamachi.org> In-Reply-To: <1108647034.51832.1088.camel@unknown.hamachi.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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-02-16 at 16:42, Joseph Galbraith wrote: > >>We just had a user request us to start a shell session >>for them in an arbitrary directory. >> >>I was wondering what people would think of the following >>extension (for the session channel only): >> >>byte SSH_MSG_CHANNEL_REQUEST >>uint32 recipient channel >>string "home-directory" >>boolean want reply >>string path to use as home directory [UTF-8] > > > starting the session in an arbitrary directory does not to me imply > setting $HOME. > > clearly: > > 1) reading authorization information (~/.ssh/authorized_keys or > ~/.*hosts) from a client-specified directory is an incredibly bad idea. > I hope nobody's suggesting that but I run into bad ideas like this often > enough that I feel compelled to point it out... Oh, definitely. "home-directory" might have been the wrong name... think "initial-working-directory" instead. > 2) setting $HOME after authentication could be accomplished by the env > request Niels mentioned. Works under unix, but no place else. > 3) setting the working directory to something other than $HOME could be > accomplished in most shells by sending over a compound command. if the > account's shell is not a normal shell, you can't do that -- but in that case > the account is may also be a captive environment, where setting either of > the working directory or $HOME might violate the assumption of that > captive environment. This works in the unix world. This could be made to work in the NT world for shell, but perhaps not for exec. And it doesn't work at all for VMS. It is pretty easy to come up with a solution that will work most places, or require user configuration to get right. I was aiming for a solution that could just work regardless of the system I was connecting to... but, given the reality of restricted shells, I think the risk vs. value doesn't make it worth while to push forward. Thanks everyone for pointing out the holes in my hare-brained scheme. Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 11:57:56 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22872 for ; Thu, 17 Feb 2005 11:57:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EC93A5262; Thu, 17 Feb 2005 16:57:52 +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 8ABC4516A for ; Thu, 17 Feb 2005 16:57:50 +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 j1HGvnOJ000189; Thu, 17 Feb 2005 09:57:49 -0700 (MST) Received: from thunk (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 j1HGvnOp015920; Thu, 17 Feb 2005 11:57:49 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1HGvmmu020804; Thu, 17 Feb 2005 11:57:48 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1HGvmvi020803; Thu, 17 Feb 2005 11:57:48 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Session channel extension to specify home directory? From: Bill Sommerfeld To: Joseph Galbraith Cc: "ietf-ssh@netbsd.org" In-Reply-To: <4214C2B7.9090507@vandyke.com> References: <4213BE4D.7090007@vandyke.com> <1108647034.51832.1088.camel@unknown.hamachi.org> <4214C2B7.9090507@vandyke.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1108659467.20616.9.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 17 Feb 2005 11:57:48 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-02-17 at 11:13, Joseph Galbraith wrote: > but, given the reality of restricted shells, I think the risk vs. value doesn't > make it worth while to push forward. ftpd has the same problem with restricted shells; the usual policy IIRC is for ftpd to require that the user's shell be listed in /etc/shells. (restricted shells and the like are typically not listed). > Thanks everyone for pointing out the holes in my hare-brained scheme. (wg chair hat off) no, this might be worth pursuing. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 12:28:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29476 for ; Thu, 17 Feb 2005 12:28:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 22BF65229; Thu, 17 Feb 2005 17:28:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 56C79516A for ; Thu, 17 Feb 2005 17:28:22 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 1C9421B808C; Thu, 17 Feb 2005 18:28:15 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 02285-01-2; Thu, 17 Feb 2005 18:27:56 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 5CB6A1B803D; Thu, 17 Feb 2005 18:27:56 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1HHRtXa008182; Thu, 17 Feb 2005 18:27:56 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1HHRqUY008179; Thu, 17 Feb 2005 18:27:52 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: Bill Sommerfeld , "ietf-ssh@netbsd.org" Subject: Re: Session channel extension to specify home directory? References: <4213BE4D.7090007@vandyke.com> <1108647034.51832.1088.camel@unknown.hamachi.org> <4214C2B7.9090507@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 17 Feb 2005 18:27:51 +0100 In-Reply-To: <4214C2B7.9090507@vandyke.com> Message-ID: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > > 2) setting $HOME after authentication could be accomplished by the > > env request Niels mentioned. > > Works under unix, but no place else. I don't see the problem. Your sshd server on NT is free to special case "HOME", when it appears in a SSH_MSG_CHANNEL_REQUEST "env", in any way it likes. It may be desirable to have some shared view about what setting very special variables like "HOME" should mean on various systems, but it's not essential. The effect of setting of *any* environment variable with SSH_MSG_CHANNEL_REQUEST "env" is inherently implementation defined. Keep the protocol simple. If one can implement a new feature in a reasonable straight forward way with the existing protocol, then don't invent new request types. And this principle is even more important for features that are obscure or useful only for a small number of users. (And if you think that the particular name "HOME" is a bad choice, you can use "CWD" or "SSHD_INITIAL_WORKING_DIRECTORY_FOR_SESSIONS"). > It is pretty easy to come up with a solution that will > work most places, or require user configuration to get right. Huh? How are you going to make it work without user configuration? The *default* behaviour of any reasonable client will still be to *not* send any home-directory request, and then sessions will be started in the default home directory for the user, whatever that happens to mean on the server. To make use of the feature at all, the user has to learn to say --with-cwd /some/place/on/the/drive when connecting to a system where "/some/place/on/the/drive" makes sense. I don't think that is going to be significantly easier to learn, than to say --with-env HOME=/some/place/on/the/drive or --with-env CWD=/some/place/on/the/drive when connecting to systems where the corresponding environment variable and value make sense. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 13:17:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12485 for ; Thu, 17 Feb 2005 13:17:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9AE93524C; Thu, 17 Feb 2005 18:17:00 +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 39C86516A for ; Thu, 17 Feb 2005 18:16:58 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa05709; 17 Feb 2005 13:15 EST Date: Thu, 17 Feb 2005 13:15:39 -0500 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses Message-ID: <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01QXXMV6vdQcuNwETYdPP8xtjnA4LIqUWu6vq8d/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 Thursday, February 17, 2005 05:22:50 AM -0800 Chris Lonvick wrote: > The 'address to bind' and 'port number to bind' specify the IP address > or domain name and port to which the socket to be listened is bound. > Some strings used for the 'address to bind' have special-case > semantics. > > "" means that connections are to be accepted on all protocol > families supported by the SSH implementation. > > "0.0.0.0" means to listen on all IPv4 addresses. > > "::" means to listen on all IPv6 addresses. > > "localhost" means to listen on all protocol families supported by > the SSH implementation on loopback addresses only, [RFC3330] and > [RFC3513]. > > "127.0.0.1" and "::1" indicate listening on the loopback > interfaces for IPv4 and IPv6 respectively. > > Note that the client can still filter connections based on information > passed in the open request. Looks good overall, but there is an issue we should be aware of even if we decide not to make any change as a result. The difference between addresses and interfaces has already been pointed out, and the text has been altered appropriately. However, a similar issue applies to loopback addresses and interfaces -- they are not always bound together. A host may have multiple loopback interfaces only one of which is assigned the canonical loopback address -- the others may have alternate-loopback, private-use, or even routable addresses. Similarly, the loopback address may have been used on a physical interface, or (more likely), it may be possible to receive packets on the loopback address via a non-loopback interface. We should be careful to specify exactly what we mean by "localhost", "127.0.0.1", and "::1". Do we mean that the ssh server should bind to the loopback address, or that it should listen on all loopback interfaces, regardless of address? -- 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 Thu Feb 17 14:01:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21485 for ; Thu, 17 Feb 2005 14:01:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0089552D1; Thu, 17 Feb 2005 19:01:22 +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 D0E905166 for ; Thu, 17 Feb 2005 19:01:20 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA25438; Thu, 17 Feb 2005 14:01:16 -0500 (EST) From: der Mouse Message-Id: <200502171901.OAA25438@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: Thu, 17 Feb 2005 13:55:25 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses In-Reply-To: <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > The difference between addresses and interfaces has already been > pointed out, and the text has been altered appropriately. However, a > similar issue applies to loopback addresses and interfaces -- Well spotted. I would have mentioned it myself when I brought up address-vs-interface elsewhere if I'd noticed it. Here too I think using "interfaces" is wrong. However, in this case I'm much less sure that using "addresses" is right. For IPv6, there is exactly one loopback address, and it is ::1. But for IPv4, all of 127/8 is defined as loopback, and it's not clear whether "127.0.0.1" should mean just listen on 127.0.0.1, or on all of 127/8 (which latter is hard to do on many systems, and is not what most software does). /~\ 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 Feb 17 14:06:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21919 for ; Thu, 17 Feb 2005 14:06:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0416452E0; Thu, 17 Feb 2005 19:06:21 +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 F3B175166 for ; Thu, 17 Feb 2005 19:06:16 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7147306; Thu, 17 Feb 2005 12:06:15 -0700 Message-ID: <4214EB2B.2030605@vandyke.com> Date: Thu, 17 Feb 2005 12:06:19 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> <200502171901.OAA25438@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200502171901.OAA25438@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: >>The difference between addresses and interfaces has already been >>pointed out, and the text has been altered appropriately. However, a >>similar issue applies to loopback addresses and interfaces -- > > > Well spotted. I would have mentioned it myself when I brought up > address-vs-interface elsewhere if I'd noticed it. > > Here too I think using "interfaces" is wrong. However, in this case > I'm much less sure that using "addresses" is right. For IPv6, there is > exactly one loopback address, and it is ::1. But for IPv4, all of > 127/8 is defined as loopback, and it's not clear whether "127.0.0.1" > should mean just listen on 127.0.0.1, or on all of 127/8 (which latter > is hard to do on many systems, and is not what most software does). I would definitely say "127.0.0.1" should mean 127.0.0.1, and "127.0.0.2" should mean 127.0.0.2 I would also vote for "localhost" meaning 127.0.0.1 for the IPv4 protocol + canonical localhost address for any other protocols. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 15:31:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01934 for ; Thu, 17 Feb 2005 15:31:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A6E652FF; Thu, 17 Feb 2005 20:31:31 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 497415166 for ; Thu, 17 Feb 2005 20:31:27 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 0B27D1B803D; Thu, 17 Feb 2005 21:31:20 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 05217-02-59; Thu, 17 Feb 2005 21:31:09 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id AB1EF1B803A; Thu, 17 Feb 2005 21:31:09 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1HKV9Xa010087; Thu, 17 Feb 2005 21:31:09 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1HKV5bd010084; Thu, 17 Feb 2005 21:31:05 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 17 Feb 2005 21:31:04 +0100 In-Reply-To: <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> Message-ID: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > We should be careful to specify exactly what we mean by "localhost", > "127.0.0.1", and "::1". Do we mean that the ssh server should bind to > the loopback address, or that it should listen on all loopback > interfaces, regardless of address? As for IPv6, my reading of RFC3513 is that ::1 is the only localhost address. One may be able to set up routing for other addresses so that they behave the same way ::1, but I don't think that's anything an ssh implementation should be required to know about. For IPv6, "localhost interface" = "localhost address" = "::1" seems to be consistent with the referenced RFC, so I don't think there's any ambiguity. For IPv4, the entire block 127.0.0.0/8 is reserved for localhost addresses. My feeling is that it should be sufficient, in practically all cases, to listen on 127.0.0.1. In the uncommon case that there are several configured loopback adresses, 127.0.0.1 *ought* to be one of them. If 127.0.0.x, x != 1, is a configured address, it may or may not make sense to have the ssh server to listen on that address too, in addition to 127.0.0.1. I can't make a strong and universal recommendation either way, so I think this choice should be left to the implementation. I would expect most implementation to treat "localhost" and "127.0.0.1" as synonyms (within IPv4). If we absolutely need to clarify it, we could say something like For IPv4, a large block, 127.0.0.0/8, is reserved for localhost addresses. Implementations MAY/SHOULD treat 127.0.0.1 as the only IPv4 localhost address. Listening on other addresses in this block, when "localhost" is requested, is OPTIONAL. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 17 16:11:23 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05668 for ; Thu, 17 Feb 2005 16:11:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id F333352E7; Thu, 17 Feb 2005 21:11:17 +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 79534516A for ; Thu, 17 Feb 2005 21:11:15 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa05919; 17 Feb 2005 16:11 EST Date: Thu, 17 Feb 2005 16:11:05 -0500 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses Message-ID: <4DEE1F2F2D8F5F9B0FE44AD7@sirius.fac.cs.cmu.edu> In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> Originator-Info: login-token=Mulberry:01E5mkjX0BGQFf5BwORhfU/KoL27iazR2ADtLySRk=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Thursday, February 17, 2005 09:31:04 PM +0100 Niels M=F6ller=20 wrote: > Jeffrey Hutzelman writes: > >> We should be careful to specify exactly what we mean by "localhost", >> "127.0.0.1", and "::1". Do we mean that the ssh server should bind to >> the loopback address, or that it should listen on all loopback >> interfaces, regardless of address? > > As for IPv6, my reading of RFC3513 is that ::1 is the only localhost > address. One may be able to set up routing for other addresses so that > they behave the same way ::1, but I don't think that's anything an ssh > implementation should be required to know about. For IPv6, "localhost > interface" =3D "localhost address" =3D "::1" seems to be consistent with > the referenced RFC, so I don't think there's any ambiguity. No; you're making the same mistake of confusing an interface with an=20 address. I believe that ::1 is the only loopback address; that is, it is=20 the only address that means "the same machine". A loopback _interface_ is one for which traffic sent on that interface is=20 only received on that interface. Several operating systems allow the=20 creation of multiple of these, and you can assign them whatever address you = want and they still behave the same way. In some cases you can play games=20 like setting up a loopback interface with a routable address, which is then = reachable via TCP from outside the machine, even though it is not the=20 address of any of the machine's physical interfaces. This _does_ happen, and it has nothing to do with what network protocol=20 you're running. We had to work around this in AFS, to avoid advertising=20 addresses of loopback devices. I think we want to be clear that if the client says to listen on=20 'localhost', the server SHOULD NOT listen on non-loopback addresses just=20 because they happen to be the configured addresses of loopback interfaces. -- 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 Fri Feb 18 03:39:17 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05443 for ; Fri, 18 Feb 2005 03:39:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7C3315383; Fri, 18 Feb 2005 08:39:08 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id C46E8516A for ; Fri, 18 Feb 2005 08:39:04 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id DCA2B1B806D; Fri, 18 Feb 2005 09:38:57 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 13530-01-33; Fri, 18 Feb 2005 09:38:46 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 6F24B1B8058; Fri, 18 Feb 2005 09:38:46 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1I8ckXa023952; Fri, 18 Feb 2005 09:38:46 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1I8cfV3023949; Fri, 18 Feb 2005 09:38:41 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: tcpip-forward requests and bind addresses References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> <4DEE1F2F2D8F5F9B0FE44AD7@sirius.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 18 Feb 2005 09:38:41 +0100 In-Reply-To: <4DEE1F2F2D8F5F9B0FE44AD7@sirius.fac.cs.cmu.edu> Message-ID: Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > A loopback _interface_ is one for which traffic sent on that interface > is only received on that interface. Several operating systems allow > the creation of multiple of these, and you can assign them whatever > address you want and they still behave the same way. Is there any functional difference between * creating two loopback interfaces, and assing them one address each, 127.0.0.1 and 192.0.2.1. * using a single loopback interface, with two assigned addresses, 127.0.0.1 and 192.0.2.1. In the second case, I guess one can set up a route saying that 192.0.2.1 is reachable via the localhost interface, and forward packets received on other packets to the loopback interface, but I don't see what one can achieve by doing that. For ssh forwarding, the question is whether or it's desirable, in this case, that ssh localhost forwarding listens 192.0.2.1. This is too obscure to me. Why would anybody setup addresses and routing so that packets are forwarded do an address on the loopback interface? Is the point to treat some remote processes as if they were local? Then it might make sense to have ssh treat them as local too. I'm curiuos if you would like to explain this, but I feel we're getting slightly off-topic. Back to the proposed text: > "localhost" means to listen on all protocol families supported by > the SSH implementation on loopback addresses only, [RFC3330] and > [RFC3513]. This doesn't talk about interfaces, only addresses. For IPv6, that's only one addrss (according to RFC3513). For IPv4 one have the choice of either using only the canonical loopback address, or all configured addresses in the entire loopback block. I don't think it matters much, and can be left to the implementation. IPv4 addresses outside of the 127.0.0.0/8 block should never come into play. A possible clarification is "localhost" means to listen on all protocol families supported by the SSH implementation, on their respective canonical loopback addresses only, [RFC3330] and [RFC3513]. > "127.0.0.1" and "::1" indicate listening on the loopback > interfaces for IPv4 and IPv6 respectively. If we change this to say "address" instead of "interfaces", does that make everybody happy? Like "0.0.0.0" and "::", these really aren't special cases. /Regards, From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 07:00:37 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22769 for ; Fri, 18 Feb 2005 07:00:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1CAFA5397; Fri, 18 Feb 2005 12:00:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cs.gmu.edu (cs.gmu.edu [129.174.87.2]) by mail.netbsd.org (Postfix) with ESMTP id 2D45B516A for ; Fri, 18 Feb 2005 12:00:30 +0000 (UTC) Received: from cs1.gmu.edu (cs1 [129.174.87.240]) by cs.gmu.edu (8.12.9+Sun/8.12.9) with ESMTP id j1IC0Tcb002669 for ; Fri, 18 Feb 2005 07:00:29 -0500 (EST) Received: from cs1.gmu.edu (localhost [127.0.0.1]) by cs1.gmu.edu (8.12.9+Sun/8.12.2) with ESMTP id j1IC0TOL005000 for ; Fri, 18 Feb 2005 07:00:29 -0500 (EST) Received: (from mgyger@localhost) by cs1.gmu.edu (8.12.9+Sun/8.12.2/Submit) id j1IC0Tb7004999 for ietf-ssh@NetBSD.org; Fri, 18 Feb 2005 07:00:29 -0500 (EST) Message-Id: <200502181200.j1IC0Tb7004999@cs1.gmu.edu> Subject: Re: UTF8 In-Reply-To: from =?ISO-8859-1?Q?Niels_M=F6ller?= at "Jan 4, 2005 01:45:01 pm" To: ietf-ssh@NetBSD.org Date: Fri, 18 Feb 2005 13:00:29 +0100 (CET) From: markus@gyger.org (Markus Gyger) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Niels Moeller writes: > Please leave the file system issues out of it for now. What's of > primary importantance are the core drafts, and those deal with > usernames and passwords in utf8 form, *not* file names. Are there any directions on what encoding SSH_MSG_CHANNEL_REQUEST with the "exec" request type should use for the command string (for "subsystem" it is specified but there sems to be no info for "exec" in connect-23)? Markus From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 09:19:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05366 for ; Fri, 18 Feb 2005 09:19:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B771A53C4; Fri, 18 Feb 2005 14:19:42 +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 B5D15516A for ; Fri, 18 Feb 2005 14:19:40 +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 j1IEHVNV009279; Fri, 18 Feb 2005 06:17:31 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j1IEHTOp014854; Fri, 18 Feb 2005 09:17:30 -0500 (EST) Subject: Re: tcpip-forward requests and bind addresses From: Bill Sommerfeld To: Niels M?ller Cc: Jeffrey Hutzelman , Chris Lonvick , "ietf-ssh@netbsd.org" In-Reply-To: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> <4DEE1F2F2D8F5F9B0FE44AD7@sirius.fac.cs.cmu.edu> Content-Type: text/plain; charset=ASCII Message-Id: <1108736190.51832.1216.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 18 Feb 2005 09:16:33 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-02-18 at 03:38, Niels M?ller wrote: > This is too > obscure to me. Why would anybody setup addresses and routing so that > packets are forwarded do an address on the loopback interface? Is the > point to treat some remote processes as if they were local? No. This is a high-availability hack generally used for cisco router management addresses and also for multi-homed high value servers trusted to participate in an IGP (OSPF/RIP/...), to avoid single points of failure and to allow them to be moved around in the site topology without being renumbered. The hosts inject one or more /32 routes into the local routing system, and the routers find the best path to the hosts. The additional address is put on a virtual interface -- often lo0 on unixes -- so that failure/removal of one of the physical interfaces doesn't cause it to disappear. solaris 10 contains a virtual "vni" interface driver specifically so you don't have to put these addresses on lo0 where they might be mistaken for a trusted loopback-only address. > Then it might make sense to have ssh treat them as local too. no, these are real externally visible addresses. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 09:34:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06773 for ; Fri, 18 Feb 2005 09:34:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 523AB53CB; Fri, 18 Feb 2005 14:34:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.netbsd.org (Postfix) with ESMTP id 695C6516A for ; Fri, 18 Feb 2005 14:34:11 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 18 Feb 2005 06:34:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1IEY8uC028445 for ; Fri, 18 Feb 2005 06:34:09 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA05180 for ; Fri, 18 Feb 2005 06:34:08 -0800 (PST) Date: Fri, 18 Feb 2005 06:34:08 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Core IDs Submitted In-Reply-To: <1108736190.51832.1216.camel@unknown.hamachi.org> Message-ID: References: <41FA6F3D.2040501@zip.com.au> <421133B1.8080408@zip.com.au> <200502151755.MAA22837@Sparkle.Rodents.Montreal.QC.CA> <421284F1.3010208@zip.com.au> <200502160511.AAA06463@Sparkle.Rodents.Montreal.QC.CA> <1EDBB88500273D07233BA99E@sirius.fac.cs.cmu.edu> <4DEE1F2F2D8F5F9B0FE44AD7@sirius.fac.cs.cmu.edu> <1108736190.51832.1216.camel@unknown.hamachi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I've submitted the core IDs to the ID Editor. Notes on the new versions: Now using xml2rfc 1.28, the prior set of IDs were created using 1.26. [ARCH] - included section to explain the use of 'field' and "value" in Conventions section 3. - duplicated in all other IDs. [ARCH] - included "Traffic Analysis" section. [NUMBERS] - Removal of Message numbers 30, 31 and 60 from Section 4.1.2. [NUMBERS] - Message Number future assignments in 4.1.3. [NUMBERS] - Explanation of kex names duplicated from [TRANS] in 4.10. [CONNECT] - assignment of 'address to listen' in 7.1. [TRANS] - Explanation of kex names in 6.5. [TRANS] - Removal of SPKI stuff in 6.6. [USERAUTH] - banner message nit in 5.4. All - various spelling and grammar corrections along with 'field' and "value" modifications. For those who can't wait for them to show up in the ID repository, I've placed them here: http://www.employees.org/~lonvick/secsh-wg/2005-feb-18/ This directory also contains the 'diffs' from prior versions as well as the xml. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 09:42:21 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07692 for ; Fri, 18 Feb 2005 09:42:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 643D053D5; Fri, 18 Feb 2005 14:42:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 303E4516A for ; Fri, 18 Feb 2005 14:42:14 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 8F6251B806E; Fri, 18 Feb 2005 15:41:54 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 23427-01-54; Fri, 18 Feb 2005 15:41:37 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 0BB3A1B8071; Fri, 18 Feb 2005 15:41:36 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1IEfZXa028173; Fri, 18 Feb 2005 15:41:35 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1IEfUex028170; Fri, 18 Feb 2005 15:41:30 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: markus@gyger.org (Markus Gyger) Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200502181200.j1IC0Tb7004999@cs1.gmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 18 Feb 2005 15:41:30 +0100 In-Reply-To: <200502181200.j1IC0Tb7004999@cs1.gmu.edu> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit markus@gyger.org (Markus Gyger) writes: > Niels Moeller writes: > > Please leave the file system issues out of it for now. What's of > > primary importantance are the core drafts, and those deal with > > usernames and passwords in utf8 form, *not* file names. > > Are there any directions on what encoding SSH_MSG_CHANNEL_REQUEST > with the "exec" request type should use for the command string > (for "subsystem" it is specified but there sems to be no info > for "exec" in connect-23)? I've never thought about the encoding issues for this string before. It's not specified. Note that also the channel data is often text, and its encoding is also not specified at all by the ssh protocols. In practice, * You have to guess what character system is used by the default session. * This will probably be a pain if local and remote systems use different character sets (say latin-1/utf8). * It's easier to let the client environment adapt to the server environment conventions than vice versa. But for now, users have to ensure manually that they are using the same character set locally and remotely. If you e.g. want to login to a server that lives in utf8-land, and your local environment doesn't use utf8, then you'd better use some local terminal emulator that understands utf8. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 12:31:37 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10737 for ; Fri, 18 Feb 2005 12:31:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 517915180; Fri, 18 Feb 2005 17:31:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cs.gmu.edu (cs.gmu.edu [129.174.87.2]) by mail.netbsd.org (Postfix) with ESMTP id ABBEB516A for ; Fri, 18 Feb 2005 17:31:30 +0000 (UTC) Received: from cs1.gmu.edu (cs1 [129.174.87.240]) by cs.gmu.edu (8.12.9+Sun/8.12.9) with ESMTP id j1IHVTcb008017 for ; Fri, 18 Feb 2005 12:31:29 -0500 (EST) Received: from cs1.gmu.edu (localhost [127.0.0.1]) by cs1.gmu.edu (8.12.9+Sun/8.12.2) with ESMTP id j1IHVTOL008850 for ; Fri, 18 Feb 2005 12:31:29 -0500 (EST) Received: (from mgyger@localhost) by cs1.gmu.edu (8.12.9+Sun/8.12.2/Submit) id j1IHVTJg008849 for ietf-ssh@netbsd.org; Fri, 18 Feb 2005 12:31:29 -0500 (EST) Message-Id: <200502181731.j1IHVTJg008849@cs1.gmu.edu> Subject: VFLUSH vs. VDISCARD To: ietf-ssh@NetBSD.org Date: Fri, 18 Feb 2005 18:31:29 +0100 (CET) From: markus@gyger.org (Markus Gyger) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit [SSH-CONNECT] mentiones in Encoding of Terminal Modes: 15 VFLUSH Character to flush output. [...] 18 VDISCARD Toggles the flushing of terminal output. There are systems that simply #define VDISCARD VFLUSH and also treat stty flush ^o and stty discard ^o the same. Are there implementations where they are distinct? SUSv3 only informatively mentions VDISCARD as reserved: http://opengroup.org/onlinepubs/009695399/basedefs/termios.h.html#tag_13_74_04 Markus From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 15:31:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09343 for ; Fri, 18 Feb 2005 15:31:02 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id F0A86526A; Fri, 18 Feb 2005 20:30:52 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 304A1516A for ; Fri, 18 Feb 2005 20:30:50 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09329; Fri, 18 Feb 2005 15:30:47 -0500 (EST) Message-Id: <200502182030.PAA09329@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-26.txt Date: Fri, 18 Feb 2005 15:30:47 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-userauth-26.txt Pages : 17 Date : 2005-2-18 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-26.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-userauth-26.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-userauth-26.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-2-18144604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-26.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144604.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 16:17:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18319 for ; Fri, 18 Feb 2005 16:17:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5CFEE53A8; Fri, 18 Feb 2005 21:16:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id AEEC75165 for ; Fri, 18 Feb 2005 21:16:52 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09410; Fri, 18 Feb 2005 15:31:30 -0500 (EST) Message-Id: <200502182031.PAA09410@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-23.txt Date: Fri, 18 Feb 2005 15:31:30 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-transport-23.txt Pages : 31 Date : 2005-2-18 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-23.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-transport-23.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-transport-23.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-2-18144630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144630.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 16:17:13 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18485 for ; Fri, 18 Feb 2005 16:17:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0036F53B2; Fri, 18 Feb 2005 21:17:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 24073516A for ; Fri, 18 Feb 2005 21:16:54 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09394; Fri, 18 Feb 2005 15:31:21 -0500 (EST) Message-Id: <200502182031.PAA09394@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-11.txt Date: Fri, 18 Feb 2005 15:31:21 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : C. Lonvick Filename : draft-ietf-secsh-assignednumbers-11.txt Pages : 21 Date : 2005-2-18 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-11.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-assignednumbers-11.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-assignednumbers-11.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-2-18144624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144624.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 16:17:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18641 for ; Fri, 18 Feb 2005 16:17:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 617D453A4; Fri, 18 Feb 2005 21:17:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id CE89853B0 for ; Fri, 18 Feb 2005 21:16:56 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09340; Fri, 18 Feb 2005 15:31:00 -0500 (EST) Message-Id: <200502182031.PAA09340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-24.txt Date: Fri, 18 Feb 2005 15:31:00 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-connect-24.txt Pages : 24 Date : 2005-2-18 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.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-connect-24.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-connect-24.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-2-18144610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144610.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 16:17:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18851 for ; Fri, 18 Feb 2005 16:17:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DD6EC5450; Fri, 18 Feb 2005 21:17:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 41E415165 for ; Fri, 18 Feb 2005 21:16:59 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09376; Fri, 18 Feb 2005 15:31:11 -0500 (EST) Message-Id: <200502182031.PAA09376@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-21.txt Date: Fri, 18 Feb 2005 15:31:11 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : C. Lonvick Filename : draft-ietf-secsh-architecture-21.txt Pages : 3 Date : 2005-2-18 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-21.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-architecture-21.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-architecture-21.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-2-18144618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144618.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 18 21:29:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13233 for ; Fri, 18 Feb 2005 21:29:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1019251F5; Sat, 19 Feb 2005 02:29:04 +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 7047A5165 for ; Sat, 19 Feb 2005 02:29:00 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa08341; 18 Feb 2005 21:28 EST Date: Fri, 18 Feb 2005 21:28:37 -0500 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Markus Gyger Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 Message-ID: In-Reply-To: References: <200502181200.j1IC0Tb7004999@cs1.gmu.edu> Originator-Info: login-token=Mulberry:01rM7W1RY2S0n4GU5W30wGRENADQAzAk8ZQwQ64k4=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, February 18, 2005 03:41:30 PM +0100 Niels M=F6ller=20 wrote: > markus@gyger.org (Markus Gyger) writes: > >> Niels Moeller writes: >> > Please leave the file system issues out of it for now. What's of >> > primary importantance are the core drafts, and those deal with >> > usernames and passwords in utf8 form, *not* file names. >> >> Are there any directions on what encoding SSH_MSG_CHANNEL_REQUEST >> with the "exec" request type should use for the command string >> (for "subsystem" it is specified but there sems to be no info >> for "exec" in connect-23)? > > I've never thought about the encoding issues for this string before. > It's not specified. Note that also the channel data is often text, and > its encoding is also not specified at all by the ssh protocols. In > practice, > > * You have to guess what character system is used by the default > session. > > * This will probably be a pain if local and remote systems use > different character sets (say latin-1/utf8). > > * It's easier to let the client environment adapt to the server > environment conventions than vice versa. > > But for now, users have to ensure manually that they are using the > same character set locally and remotely. If you e.g. want to login to > a server that lives in utf8-land, and your local environment doesn't > use utf8, then you'd better use some local terminal emulator that > understands utf8. It's interesting that I was just thinking about this very problem earlier=20 this week. Ultimately, I came to the conclusion that it's probably best=20 not to try to specify the character set of channel data, because=20 operational experience shows that what we have now actually works fairly=20 well, and trying to "fix" it may well create more problems than it would=20 solve. Fundamentally, I see ssh channels as doing two things: (1) allowing the user to have a local terminal on a remote machine (2) carrying non-textual protocols like sftp or X11 or arbitrary traffic via port-forwarding I think it's pretty non-controversial that for (2), we don't want the ssh=20 protocol modifying the data stream. I'd like to suggest that case (1) is really the same thing. In this case=20 we're not carrying _text_; we're carrying communication between a terminal=20 and programs using that terminal, which is actually a non-textual protocol=20 that happens to carry a lot of text. The ssh protocol already provides a means to inform the server software of=20 the user's terminal type; servers (or the application software they run)=20 will use this information to determine things like what are valid control=20 sequences for the terminal, including how to determine what the available=20 character sets are and how to switch between them. It would be pretty sad=20 if an application switched character sets and stopped working because the=20 ssh client and/or server didn't notice the change. Even worse, for a shell we actually can't tell the difference between (1)=20 and (2). For an interactive login (1) is probably the case, but scp runs a = binary protocol over a shell connection, which is actually (2). So if someone wants to define a set of extensions which define a UTF-8=20 based network virtual terminal, I'd not object. But changing the default=20 behavior of the existing session channel is probably a bad idea. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Feb 20 07:47:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29564 for ; Sun, 20 Feb 2005 07:47:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 73CE152D4; Sun, 20 Feb 2005 12:46:53 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from draco.cus.cam.ac.uk (draco.cus.cam.ac.uk [131.111.8.18]) by mail.netbsd.org (Postfix) with ESMTP id 1D8D1516E for ; Sun, 20 Feb 2005 12:46:51 +0000 (UTC) Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1D2qU5-0001hO-4V for ietf-ssh@netbsd.org; Sun, 20 Feb 2005 12:46:49 +0000 Date: Sun, 20 Feb 2005 12:46:49 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Nits in current drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've mentioned some of these before, but all of them still apply to the set of drafts released on Friday. draft-ietf-secsh-transport-23.txt: Section 6.4: replace "The hash algorithms are described in [SCHNEIER]." with "The SHA-1 hash algorithm is described in [FIPS-180-2]. The MD5 hash algorithm is described in [RFC1321]." Section 6.6: replace each occurrence of "the SHA-1 hash" with "the SHA-1 hash, as defined in [FIPS-180-2],". Section 6.6: replace "according to [SCHNEIER] and [RFC3447]" with "according to the RSASSA-PKCS1-v1_5 scheme of [RFC3447]". Sections 8.1, 8.2: replace each occurrence of "SHA-1" with "SHA-1, as defined in [FIPS-180-2],". Section 15.1: delete references [RFC2693] and [RFC3280]. Section 15.1: add references: The MD5 Message-Digest Algorithm Secure Hash Standard (SHS) National Institute of Standards and Technology (NIST) The references to other FIPS PUBs could do with all having the same format and being in numerical order. I'd suggest replacing them with: Data Encryption Standard (DES) National Institute of Standards and Technology (NIST) Digital Signature Standard (DSS) National Institute of Standards and Technology (NIST) Advanced Encryption Standard (AES) National Institute of Standards and Technology (NIST) draft-ietf-secsh-connect-24.txt: Section 5.2: replace second paragraph with: After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Implementations MUST correctly handle window sizes of up to 2^32 - 1 bytes. The window MUST NOT be increased above 2^32 - 1 bytes. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Feb 20 21:21:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07168 for ; Sun, 20 Feb 2005 21:21:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 07FAF5227; Mon, 21 Feb 2005 02:21:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpc.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13]) by mail.netbsd.org (Postfix) with ESMTP id C76B6516C for ; Mon, 21 Feb 2005 02:21:30 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 9B44C340DE; Mon, 21 Feb 2005 15:21:24 +1300 (NZDT) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15836-29; Mon, 21 Feb 2005 15:21:24 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 837AF34068; Mon, 21 Feb 2005 15:21:24 +1300 (NZDT) 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 F1CC737743; Mon, 21 Feb 2005 15:21:23 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D33CS-00087a-00; Mon, 21 Feb 2005 15:21:28 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts In-Reply-To: Message-Id: Date: Mon, 21 Feb 2005 15:21:28 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Harris writes: >I've mentioned some of these before, but all of them still apply to the set >of drafts released on Friday. Same here: The OpenPGP portions of section 6.6 still don't provide sufficient information to create an interoperable implementation. "OpenPGP compatible binary format" for the signature could be almost anything, since OpenPGP has a whole pile of signature components, attributes, and so on. The easiest way to resolve this I think is to require that signatures *only* be in "ssh-xyz format", regardless of the certificate format used (i.e. don't tie the signature format to the key format). I can't see any good reason for requiring the use of complex non-SSH signature formats just because the key is communicated using a different format, and this would also resolve the problem with the ambiguity of the (now-deleted) X.509 format as well, since the X.509 cert format is well-defined, it's only the signature format which is ambiguous. So I'd propose changing the current text to: The signature for any DSS key (regardless of the key/certificate format used) is encoded as follows: string "ssh-dss" string dss_signature_blob [...] The signature for any RSA key (regardless of the key/certificate format used) is encoded as follows: string "ssh-rsa" string rsa_signature_blob This finally resolves the ongoing signature format ambiguity problem, as well as greatly reducing the complexity and implementation effort required for parsing a pile of non-SSH signature types. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Feb 20 22:22:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11518 for ; Sun, 20 Feb 2005 22:22:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C15F2523D; Mon, 21 Feb 2005 03:22:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (unknown [IPv6:3ffe:1ce1:0:bb:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id 61BA7516C for ; Mon, 21 Feb 2005 03:22:23 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 7328DE0063; Sun, 20 Feb 2005 22:22:12 -0500 (EST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts References: From: Sam Hartman Date: Sun, 20 Feb 2005 22:22:12 -0500 In-Reply-To: (Peter Gutmann's message of "Mon, 21 Feb 2005 15:21:28 +1300") 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 >>>>> "Peter" == Peter Gutmann writes: Peter> Ben Harris writes: >> I've mentioned some of these before, but all of them still >> apply to the set of drafts released on Friday. Peter> Same here: The OpenPGP portions of section 6.6 still don't Peter> provide sufficient information to create an interoperable Peter> implementation. "OpenPGP compatible binary format" for the Peter> signature could be almost anything, since OpenPGP has a Peter> whole pile of signature components, attributes, and so on. Peter> The easiest way to resolve this I think is to require that Peter> signatures *only* be in "ssh-xyz format", regardless of the Peter> certificate format used (i.e. don't tie the signature Peter> format to the key format). I can't see any good reason for Peter> requiring the use of complex non-SSH signature formats just Peter> because the key is communicated using a different format, Peter> and this would also resolve the problem with the ambiguity Peter> of the (now-deleted) X.509 format as well, since the X.509 Peter> cert format is well-defined, it's only the signature format Peter> which is ambiguous. I would feel uncomfortable with the working group making such a decision this late in the process. These drafts are before the IESG. Ideally the working group should be only need to be resolving specific discuss comments. The working group is apparently choosing to make somewhat broader changes. That's OK although it will require more review and may delay publication. However doing new design work seems inappropriate at this stage in the process. If a feature is neither sufficiently designed for interoperable implementations nor widely implemented, drop that feature. You can come back and add it later either in a revision to the core drafts or in an extension draft. (My position is somewhat ambiguous here. I'm the AD for this group but I am not the shepherd for these documents.) --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Feb 20 22:24:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11613 for ; Sun, 20 Feb 2005 22:24:22 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 742FF5258; Mon, 21 Feb 2005 03:24:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (unknown [IPv6:3ffe:1ce1:0:bb:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id D7119518D for ; Mon, 21 Feb 2005 03:24:18 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 21F91E0063; Sun, 20 Feb 2005 22:24:14 -0500 (EST) To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts References: From: Sam Hartman Date: Sun, 20 Feb 2005 22:24:14 -0500 In-Reply-To: (Ben Harris's message of "Sun, 20 Feb 2005 12:46:49 +0000 (GMT)") 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 It seems reasonable to replace the first reference to SHA-1 to be to SHA-1 as defined by FIPS. Perdhaps it is reasonable to replace the first reference in each section. However beyond that it seems reasonable to refer to it as SHA-1. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Feb 20 23:34:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17061 for ; Sun, 20 Feb 2005 23:34:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 94B595235; Mon, 21 Feb 2005 04:34:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id A30E0516C for ; Mon, 21 Feb 2005 04:34:23 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 6B1C13441A; Mon, 21 Feb 2005 17:08:21 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03735-08; Mon, 21 Feb 2005 17:08:21 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 1EBAF34358; Mon, 21 Feb 2005 17:08:21 +1300 (NZDT) 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 1B0CC37743; Mon, 21 Feb 2005 17:08:21 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D34ry-0008EK-00; Mon, 21 Feb 2005 17:08:26 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hartmans-ietf@mit.edu, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts Cc: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Mon, 21 Feb 2005 17:08:26 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Sam Hartman writes: >However doing new design work seems inappropriate at this stage in the >process. I'd agree with that, but this isn't really new design work, it's just dropping an ambiguous/underspecified format. In other words leave the cert/key section exactly as is, and just remove the underspecified signature format. So I think this meets the "drop the feature" requirement, all that's being dropped is the use of the "xyz-pgp" signature format, leaving the "xyz-pgp" key/cert format in place. (Stepping back a bit, I think the problem here has always been the tying of each non-SSH key/cert format to a corresponding non-SSH signature format, even though there's no good reason for this and the non-SSH sig format is often under-specified. Unifying all the signatures into a single format that's already universally used and widely field-tested doesn't seem like a major showstopper). Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 21 00:44:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25019 for ; Mon, 21 Feb 2005 00:44:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E936526F; Mon, 21 Feb 2005 05:44:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by mail.netbsd.org (Postfix) with ESMTP id 3CE85516C for ; Mon, 21 Feb 2005 05:44:37 +0000 (UTC) Received: by luminous.mit.edu (Postfix, from userid 1000) id 94E2176DF8; Mon, 21 Feb 2005 00:44:33 -0500 (EST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts References: From: Sam Hartman Date: Mon, 21 Feb 2005 00:44:33 -0500 In-Reply-To: (Peter Gutmann's message of "Mon, 21 Feb 2005 17:08:26 +1300") Message-ID: <87vf8mo4am.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Peter" == Peter Gutmann writes: Peter> (Stepping back a bit, I think the problem here has always Peter> been the tying of each non-SSH key/cert format to a Peter> corresponding non-SSH signature format, even though there's Peter> no good reason for this and the non-SSH sig format is often Peter> under-specified. Unifying all the signatures into a single Peter> format that's already universally used and widely Peter> field-tested doesn't seem like a major showstopper). Your parenthetical is in fact a new design decision. I don't believe that making the decision to drop the PGP signature format can be made without deciding that your parenthetical statement is the correct design and I believe making that decision at this point in the process is inappropriate. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 21 07:35:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19780 for ; Mon, 21 Feb 2005 07:35:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 377EC51E1; Mon, 21 Feb 2005 12:35:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cs.gmu.edu (cs.gmu.edu [129.174.87.2]) by mail.netbsd.org (Postfix) with ESMTP id 3BA2A515B for ; Mon, 21 Feb 2005 12:35:24 +0000 (UTC) Received: from cs1.gmu.edu (cs1 [129.174.87.240]) by cs.gmu.edu (8.12.9+Sun/8.12.9) with ESMTP id j1LCZLcb005148; Mon, 21 Feb 2005 07:35:21 -0500 (EST) Received: from cs1.gmu.edu (localhost [127.0.0.1]) by cs1.gmu.edu (8.12.9+Sun/8.12.2) with ESMTP id j1LCZLOL011312; Mon, 21 Feb 2005 07:35:21 -0500 (EST) Received: (from mgyger@localhost) by cs1.gmu.edu (8.12.9+Sun/8.12.2/Submit) id j1LCZL8Z011311; Mon, 21 Feb 2005 07:35:21 -0500 (EST) Message-Id: <200502211235.j1LCZL8Z011311@cs1.gmu.edu> Subject: Re: UTF8 In-Reply-To: from =?ISO-8859-1?Q?Niels_M=F6ller?= at "Feb 18, 2005 03:41:30 pm" To: =?ISO-8859-1?Q?Niels_M=F6ller?= Date: Mon, 21 Feb 2005 13:35:21 +0100 (CET) Cc: ietf-ssh@NetBSD.org From: markus@gyger.org (Markus Gyger) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Niels Moeller writes: > Markus Gyger writes: > > Are there any directions on what encoding SSH_MSG_CHANNEL_REQUEST > > with the "exec" request type should use for the command string > > (for "subsystem" it is specified but there sems to be no info > > for "exec" in connect-23)? > > I've never thought about the encoding issues for this string before. > It's not specified. Note that also the channel data is often text, and > its encoding is also not specified at all by the ssh protocols. In > practice, > > * You have to guess what character system is used by the default > session. > > * This will probably be a pain if local and remote systems use > different character sets (say latin-1/utf8). > > * It's easier to let the client environment adapt to the server > environment conventions than vice versa. > > But for now, users have to ensure manually that they are using the > same character set locally and remotely. If you e.g. want to login to > a server that lives in utf8-land, and your local environment doesn't > use utf8, then you'd better use some local terminal emulator that > understands utf8. In the long term, is the idea to use UTF-8 or to have it configurable? Since currently only US-ASCII is used it's not much of a problem (I don't know if there are e.g. servers that use EBCDIC). But how about e.g. the names of environment variables to be passed or the TERM names passed -- should they use the same encoding as the channel data (once they are outside of US-ASCII) or UTF-8 per default? Markus From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 21 08:43:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26172 for ; Mon, 21 Feb 2005 08:43:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CBE75516C; Mon, 21 Feb 2005 13:43:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id F0B1B52D7 for ; Mon, 21 Feb 2005 13:42:48 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 8E17E1B8059; Mon, 21 Feb 2005 14:42:31 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 32236-01-68; Mon, 21 Feb 2005 14:42:21 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 107D61B8054; Mon, 21 Feb 2005 14:42:21 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1LDgJXa024063; Mon, 21 Feb 2005 14:42:20 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1LDgBvJ024060; Mon, 21 Feb 2005 14:42:11 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: markus@gyger.org (Markus Gyger) Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200502211235.j1LCZL8Z011311@cs1.gmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 21 Feb 2005 14:42:11 +0100 In-Reply-To: <200502211235.j1LCZL8Z011311@cs1.gmu.edu> Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit markus@gyger.org (Markus Gyger) writes: > In the long term, is the idea to use UTF-8 or to have it > configurable? It seems that the world is slowly moving towards utf-8, but that development is not really in scope of the secsh wg to decide. We just go with the flow. When it has been necessary to deal with different character sets in the ssh protocols, so far the answer has been to require utf-8 on the wire. > Since currently only US-ASCII is used it's not > much of a problem Huh? I'm using latin-1 over ssh sessions all the time. I'm sure others are using utf-8 as well as a bunch of other encodings. > But how about e.g. the names of environment > variables to be passed or the TERM names passed -- should > they use the same encoding as the channel data (once they > are outside of US-ASCII) or UTF-8 per default? For names and values of environment variables, it's about as undefined as the charset for channel data. For the TERM names, these are fairly standardized, and ascii. We don't need to care until non-ascii terminal names are added to termcap/terminfo, and I doubt that will ever happen. Using plain ascii for various identifiers which are intended to be interpreted by machines rather than humans, seems to be a very deeply rooted convention. /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 21 11:42:37 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19261 for ; Mon, 21 Feb 2005 11:42:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 39C2952C1; Mon, 21 Feb 2005 16:42:26 +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 511EC518D for ; Mon, 21 Feb 2005 16:42:24 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D3GdO-0003VQ-00; Mon, 21 Feb 2005 16:42:10 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Mon, 21 Feb 2005 16:42:10 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >The easiest way to resolve this I think is to require that signatures *only* >be in "ssh-xyz format", regardless of the certificate format used (i.e. don't >tie the signature format to the key format). I think this is a bad idea for the following reasons: It forces all RSA and DSA signatures to use a SHA-1 hash, which limits them to 80 (or maybe 69) bits of security, which is likely to be insufficient fairly soon, and is very likely to be less than the security offered by the MAC and cipher in use. It forces all RSA signatures to use RSASSA-PKCS1-v1_5/SHA-1, when the same keys might be used with other signature schemes and hashes. This goes against the recommendation in section 6 of RFC 3447: A generally good cryptographic practice is to employ a given RSA key pair in only one scheme. This avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security. While RSAES-PKCS1-v1_5 (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally been employed together without any known bad interactions (indeed, this is the model introduced by PKCS #1 v1.5), such a combined use of an RSA key pair is not recommended for new applications. It makes the use of libraries (or perhaps hardware) that encapsulate complete signature schemes unnecessarily difficult, and perhaps impossible in the case of secure hardware that's only willing to use a particular signature scheme. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 21 19:20:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03368 for ; Mon, 21 Feb 2005 19:20:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0C583530F; Tue, 22 Feb 2005 00:20:28 +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 2C3495178 for ; Tue, 22 Feb 2005 00:20:26 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1D3Nmr-0005wj-00 for ietf-ssh@netbsd.org; Tue, 22 Feb 2005 00:20:25 +0000 Date: Tue, 22 Feb 2005 00:20:25 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: nits in filexfer-06 Message-ID: <20050222002025.GF7758@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list draft-ietf-secsh-filexfer-06.txt says: | 3. General Packet Format | | All packets transmitted over the secure connection are of the | following format: | | uint32 length | byte type | uint32 request-id | ... type specific fields... | byte[length] data payload | | 'length' is the length of the entire packet, excluding the length | field itself, such that, for example, for a packet type containing no | type specific fields, the length field would be 5, and 9 bytes of | data would be sent on the wire. (This is the packet format used in | the secsh transport. [2] This is wrong in two respects, and confusing in several others: * The last line of the packet description should be byte[length-5] data payload to match the rest of the language. * Two packets, SSH_FXP_INIT and SSH_FXP_VERSION, have no `request-id' field. I think it's easier to leave it out of the "General Packet Format", although it's probably worth mentioning that `request-id' exists in most packets in this section. * The inclusion of "... type specific fields ..." above this can be read to imply that there might sometimes be extra fields _between_ the "request-id" and "data payload". I presume the "type specific fields" is actually intended to refer to the "data payload" field itself. * I think "This is the packet format used in the secsh transport" could also be confusing. I'd go for something more like "This is a similar convention to that used in the secsh transport packet format". I don't see much wrong with the language in filexfer-05 and previous, TBH. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 21 21:35:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17934 for ; Mon, 21 Feb 2005 21:35:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4521B51D8; Tue, 22 Feb 2005 02:34:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by mail.netbsd.org (Postfix) with ESMTP id A29015178 for ; Tue, 22 Feb 2005 02:34:55 +0000 (UTC) Received: from [18.18.6.46] (WEST-NINETYTWO-THREE-O-ONE.MIT.EDU [18.18.6.46]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j1M2E9d0001854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Feb 2005 21:14:10 -0500 (EST) Message-ID: <421A95AE.40402@columbia.edu> Date: Mon, 21 Feb 2005 21:15:10 -0500 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200502211235.j1LCZL8Z011311@cs1.gmu.edu> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010200010402020300060602" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms010200010402020300060602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Let me remind the group that it is completely up to the terminal and the application to determine the character set and terminal type which are to be used across the data stream. Both the terminal type and the character set may be negotiated as needed. The SSH channel like the Telnet channel is a binary pipe. It is not text data. Jeffrey Altman --------------ms010200010402020300060602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMjIyMDIxNTExWjAjBgkqhkiG9w0BCQQxFgQUhXnbIeanCgG6UgsXTZTx3G/Y3OEw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAtUOJKYHg7A5s9fAJYLKk1hJm+YQN0qqqzRBg7Mb7 uGCyTwDU7W4pz1qIWdNUUJvs557OcdxJmoupxmxfQZJIRecl9/o+y0ZFeeLfydllE6sMFaVh dEWv4apU3m09qkel4mtwRYRpiQKOxRRaK9W/61u3GrVpZEV1diWb8swhpFIkVD3zp1MkPio9 wKl+71TzcCnBqfdAPf3EQhYpdep97jBCT1UoiSXAhMRZlKqjF29o94wfucJSmJGQQxegmaHA MUSV9RowGU8zHW4K9RkhSQ6KAZjpjtnQ3c349pTTYSYKlvWvRuawfY2MaB2ubWvWaiVcgfnx UyYUGpQ5IiVQRwAAAAAAAA== --------------ms010200010402020300060602-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 22 04:53:21 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07927 for ; Tue, 22 Feb 2005 04:53:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6E0A45176; Tue, 22 Feb 2005 09:53:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 09B045176 for ; Tue, 22 Feb 2005 09:53:05 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 66ACA1B8030; Tue, 22 Feb 2005 10:52:58 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 31496-01-50; Tue, 22 Feb 2005 10:52:40 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id ADE451B8023; Tue, 22 Feb 2005 10:52:40 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1M9qdXa015672; Tue, 22 Feb 2005 10:52:39 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1M9qXZI015669; Tue, 22 Feb 2005 10:52:33 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Ben Harris Cc: ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 22 Feb 2005 10:52:32 +0100 In-Reply-To: Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Ben Harris writes: > In article you write: > >The easiest way to resolve this I think is to require that signatures *only* > >be in "ssh-xyz format", regardless of the certificate format used (i.e. don't > >tie the signature format to the key format). > > I think this is a bad idea for the following reasons: > > It forces all RSA and DSA signatures to use a SHA-1 hash, which limits them > to 80 (or maybe 69) bits of security, which is likely to be insufficient > fairly soon, and is very likely to be less than the security offered by the > MAC and cipher in use. As long as we're signing an exchange hash computed with sha-1, replacing the hashing that is part of the signature processing by something stronger than sha-1 won't increase security, will it? > It forces all RSA signatures to use RSASSA-PKCS1-v1_5/SHA-1, when the same > keys might be used with other signature schemes and hashes. Strictly speaking, it's possible to use the ssh-rsa *format* with other encapsulation schemes and hashes. The format says how you put a signature bignum into the ssh protocol, it doesn't say how that bignum is computed or verified. There should be no problem to define a signature algorithm "rsa-foo-sha512" and use the same format for the generated signatures. > It makes the use of libraries (or perhaps hardware) that encapsulate > complete signature schemes unnecessarily difficult, and perhaps > impossible It's "difficult" rather than "impossible". If we ever want the signature generated by your hardware to be verified by software, that software must be able to decode the hardware's custom format and get to the underlying bignum. You can do that at the sending side (where the hardware is located), or at the receiving side (which needs to verify the signature). And for interoperability, I think it makes a lot of sense to do this conversion on the sender side, and have a single format on the wire. I think this has to be decided case by case when new certificate types are added. But unless there are strong reasons to do differently for a particular certificate type, I tend to agree with Peter. We don't need more than one way to encode the bignum in an RSA (or DSA) signature. (And for the current drafts, we just need to delete underspecified certificate formats). Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 22 06:36:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17939 for ; Tue, 22 Feb 2005 06:36:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3E0DE52B2; Tue, 22 Feb 2005 11:36:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpc.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13]) by mail.netbsd.org (Postfix) with ESMTP id 5E2BC516F for ; Tue, 22 Feb 2005 11:36:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 3B99A34A30; Wed, 23 Feb 2005 00:36:18 +1300 (NZDT) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19028-02; Wed, 23 Feb 2005 00:36:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 228B13482A; Wed, 23 Feb 2005 00:36:18 +1300 (NZDT) 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 1C16237743; Wed, 23 Feb 2005 00:36:18 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D3YL4-0001C5-00; Wed, 23 Feb 2005 00:36:26 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts In-Reply-To: Message-Id: Date: Wed, 23 Feb 2005 00:36:26 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Harris writes: >I think this is a bad idea for the following reasons: None of those seem valid. At the moment, the only signature mechanism is ssh- xyz (the others are all ambiguous, so in effect they're xyz@vendorname.com mechanisms). Therefore if a weakness is found in the hash or signature algorithm, all implementations will need to be fixed anyway. Conversely, if no weaknesses are found, there's nothing to do. In both cases it's no change from the current state of affairs. (If there was some huge deployed user base that needs to be accomodated that'd be another issue, but debating the theoretical pros and cons of something that, in 23 revisions of the spec over a period of 8(?) years, nothing has ever used, seems rather pointless). Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 22 06:44:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18954 for ; Tue, 22 Feb 2005 06:44:08 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 51D025271; Tue, 22 Feb 2005 11:44:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id 79A95516D for ; Tue, 22 Feb 2005 11:44:05 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 6475734DD4; Wed, 23 Feb 2005 00:44:04 +1300 (NZDT) 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 13917-01; Wed, 23 Feb 2005 00:44:04 +1300 (NZDT) 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 471C334CA8; Wed, 23 Feb 2005 00:44:03 +1300 (NZDT) 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 EB8A437743; Wed, 23 Feb 2005 00:44:03 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D3YSa-0001CZ-00; Wed, 23 Feb 2005 00:44:12 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, nisse@lysator.liu.se Subject: Re: Nits in current drafts Cc: ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 23 Feb 2005 00:44:12 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) >Ben Harris writes: >> It makes the use of libraries (or perhaps hardware) that encapsulate >> complete signature schemes unnecessarily difficult, and perhaps >> impossible > >It's "difficult" rather than "impossible". Just for the record, I've done SSH using both crypto coprocessors and smart cards (I'm sure Fortezza cards were never intended to be used with SSH servers :-), and doing anything *other* than the current "ssh-rsa" would be quite difficult. Everything does basic PKCS #1 v1.5 sigs, a few things do PKCS #1 OAEP, and that's about it. So the hardware argument is strongly in favour of "ssh-rsa", not against it. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 22 07:30:37 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23660 for ; Tue, 22 Feb 2005 07:30:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3714B52BF; Tue, 22 Feb 2005 12:30:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from draco.cus.cam.ac.uk (draco.cus.cam.ac.uk [131.111.8.18]) by mail.netbsd.org (Postfix) with ESMTP id 458F9516D for ; Tue, 22 Feb 2005 12:30:29 +0000 (UTC) Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1D3ZBL-00030D-TD; Tue, 22 Feb 2005 12:30:27 +0000 Date: Tue, 22 Feb 2005 12:30:27 +0000 (GMT) From: Ben Harris To: =?iso-8859-1?q?Niels_M=F6ller?= Cc: ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1109075427=:6501" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-758783491-1109075427=:6501 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 22 Feb 2005, Niels M=F6ller wrote: > As long as we're signing an exchange hash computed with sha-1, > replacing the hashing that is part of the signature processing by > something stronger than sha-1 won't increase security, will it? True, but there will eventually be KEX methods that use better hashes than= =20 SHA-1. >> It forces all RSA signatures to use RSASSA-PKCS1-v1_5/SHA-1, when the sa= me >> keys might be used with other signature schemes and hashes. > > Strictly speaking, it's possible to use the ssh-rsa *format* with > other encapsulation schemes and hashes. OK. That wasn't clear from Peter's proposal, and nor is it clear from the= =20 current draft. While I think it's silly to use "ssh-rsa" to mean "some=20 unspecified kind of RSA signature", I don't think it's actually dangerous. > (And for the current drafts, we just need to delete underspecified > certificate formats). If they're really underspecified (to the extent that two people can't=20 write interoperable implementations based solely on the spec) then yes,=20 they should be deleted and specified properly in a separate draft. --=20 Ben Harris ---559023410-758783491-1109075427=:6501-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Feb 22 09:23:57 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04692 for ; Tue, 22 Feb 2005 09:23:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 185EB51D8; Tue, 22 Feb 2005 14:23:43 +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 673015187 for ; Tue, 22 Feb 2005 14:23:41 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D3awu-0008B5-00; Tue, 22 Feb 2005 14:23:40 +0000 From: Ben Harris To: pgut001@cs.auckland.ac.nz, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Tue, 22 Feb 2005 14:23:40 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >Ben Harris writes: > >>I think this is a bad idea for the following reasons: > >None of those seem valid. At the moment, the only signature mechanism is ssh- >xyz (the others are all ambiguous, so in effect they're xyz@vendorname.com >mechanisms). Therefore if a weakness is found in the hash or signature >algorithm, all implementations will need to be fixed anyway. That, along with Niels Moller's reply, suggests that your interpretation of the meaning of your suggested amendment differs from mine. Could you thus clarify: Does your proposed amendment allow an ssh-rsa signature to use any scheme other than RSASSA-PKCS1-v1_5/SHA-1? Does your proposed amendment apply to any key format other than those defined by [SSH-TRANS] (currently ssh-rsa and pgp-sign-rsa)? If your answers to those questions are other than "no" and "yes" respectively, my objections are void (though I think your proposal needs to be clearer). -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 03:44:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13114 for ; Wed, 23 Feb 2005 03:44:22 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3979A5227; Wed, 23 Feb 2005 08:44:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id B806B516C for ; Wed, 23 Feb 2005 08:44:08 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 009FE3450A; Wed, 23 Feb 2005 21:44:04 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19193-01; Wed, 23 Feb 2005 21:44:03 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id B541E34366; Wed, 23 Feb 2005 21:44:03 +1300 (NZDT) 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 6C01A37743; Wed, 23 Feb 2005 21:44:03 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D3s7u-00034y-00; Wed, 23 Feb 2005 21:44:10 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts In-Reply-To: Message-Id: Date: Wed, 23 Feb 2005 21:44:10 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Harris writes: >Does your proposed amendment allow an ssh-rsa signature to use any scheme >other than RSASSA-PKCS1-v1_5/SHA-1? Mu :-). Currently the only scheme defined for ssh-rsa is RSASSA-PKCS1- v1_5/SHA-1, so it's "Whatever the spec says for ssh-rsa". If ssh-rsa is at some point extended to allow (say) .../SHA-256 as well then it'd be automatically accomodated. >Does your proposed amendment apply to any key format other than those defined >by [SSH-TRANS] (currently ssh-rsa and pgp-sign-rsa)? Well, because it no longer ties the signature format to the key/cert format, it allows any key format you want, but with a common (and most importantly well-defined and universally implemented) signature format ssh-rsa (or dsa). So instead of: Key Sig ssh-rsa ssh-rsa pgp-sign-rsa pgp-sign-rsa x509-sign-rsa x509-sign-rsa spki-sign-rsa spki-sign-rsa wibble-sign-rsa wibble-sign-rsa where everything in the "Sig" column except ssh-rsa is underspecified/ambiguous and therefore more or less impossible to achieve interoperability on, it'd be: Key Sig ssh-rsa ssh-rsa pgp-sign-rsa ssh-rsa x509-sign-rsa ssh-rsa spki-sign-rsa ssh-rsa wibble-sign-rsa ssh-rsa with the single universal sig format and any key format you want. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 06:14:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04013 for ; Wed, 23 Feb 2005 06:14:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E9F152C1; Wed, 23 Feb 2005 11:14:12 +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 288D4516C for ; Wed, 23 Feb 2005 11:14:10 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D3uT2-0001RZ-00; Wed, 23 Feb 2005 11:14:08 +0000 From: Ben Harris To: pgut001@cs.auckland.ac.nz, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Wed, 23 Feb 2005 11:14:08 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >Ben Harris writes: >>Does your proposed amendment allow an ssh-rsa signature to use any scheme >>other than RSASSA-PKCS1-v1_5/SHA-1? > >Mu :-). Currently the only scheme defined for ssh-rsa is RSASSA-PKCS1- >v1_5/SHA-1, so it's "Whatever the spec says for ssh-rsa". If ssh-rsa is at >some point extended to allow (say) .../SHA-256 as well then it'd be >automatically accomodated. That's a "no" for my purposes. >>Does your proposed amendment apply to any key format other than those defined >>by [SSH-TRANS] (currently ssh-rsa and pgp-sign-rsa)? > >Well, because it no longer ties the signature format to the key/cert format, >it allows any key format you want, but with a common (and most importantly >well-defined and universally implemented) signature format ssh-rsa (or dsa). That doesn't answer my question. I'll try rephrasing: Imagine I've got an RSA-based authentication system, with its own certificate format, so I define a wibble-rsa@bjh21.me.uk public-key format. It happens that my authentication system uses its keys with RSASSA-PSS internally. 1: Am I required to use the "ssh-rsa" signature format? 2: Am I required to use RSASSA-PKCS1-v1_5/SHA-1? > ssh-rsa ssh-rsa > pgp-sign-rsa pgp-sign-rsa > x509-sign-rsa x509-sign-rsa > spki-sign-rsa spki-sign-rsa > wibble-sign-rsa wibble-sign-rsa > >where everything in the "Sig" column except ssh-rsa is >underspecified/ambiguous Why is it obviously the case that all future RSA signature formats (which I assume to be represented by "wibble-sign-rsa") are going to be underspecified or ambiguous? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 07:13:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09240 for ; Wed, 23 Feb 2005 07:13:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CD9C55232; Wed, 23 Feb 2005 12:13:29 +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 D9EBE516C for ; Wed, 23 Feb 2005 12:13:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id A553A34DD3; Thu, 24 Feb 2005 01:13:20 +1300 (NZDT) 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 28121-20; Thu, 24 Feb 2005 01:13:20 +1300 (NZDT) 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 8C8DA34A72; Thu, 24 Feb 2005 01:13:20 +1300 (NZDT) 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 85F0037743; Thu, 24 Feb 2005 01:13:20 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D3vOT-0003P8-00; Thu, 24 Feb 2005 01:13:29 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz Subject: Re: Nits in current drafts In-Reply-To: Message-Id: Date: Thu, 24 Feb 2005 01:13:29 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Harris writes: >In article you write: >>Ben Harris writes: >>>Does your proposed amendment allow an ssh-rsa signature to use any scheme >>>other than RSASSA-PKCS1-v1_5/SHA-1? >> >>Mu :-). Currently the only scheme defined for ssh-rsa is RSASSA-PKCS1- >>v1_5/SHA-1, so it's "Whatever the spec says for ssh-rsa". If ssh-rsa is at >>some point extended to allow (say) .../SHA-256 as well then it'd be >>automatically accomodated. > >That's a "no" for my purposes. Well obviously it's a no because there's no other format defined, so anything that uses ssh-rsa with other than RSASSA-PKCS1-v1_5/SHA-1 is in violation of the spec. Your question was the equivalent of "Have you stopped beating your wife yet", which was why I answered "Mu", and then qualified it by saying that if ssh-rsa was extended to allow anything else then using that would be OK. >Imagine I've got an RSA-based authentication system, with its own certificate >format, so I define a wibble-rsa@bjh21.me.uk public-key format. It happens >that my authentication system uses its keys with RSASSA-PSS internally. > >1: Am I required to use the "ssh-rsa" signature format? No, you can use whatever you want, although unless you use ssh-rsa you're not going to be able to talk to anything else (obviously, that's what's implied by the xyz@foo.com format). >2: Am I required to use RSASSA-PKCS1-v1_5/SHA-1? Since RSASSA-PKCS1-v1_5/SHA-1 is the only format defined for ssh-rsa, I guess the answer is yes (see my comment above). I guess you can use anything you want in practice and still call it ssh-rsa, but your implementation won't interoperate with anything else. OTOH if you wanted to use (say) RSA-PSS, you could do by specifying rsa-pss@foo.com for the sig format. >Why is it obviously the case that all future RSA signature formats (which I >assume to be represented by "wibble-sign-rsa") are going to be underspecified >or ambiguous? It isn't obvious, but to date (through all 23 revisions of the spec) they've been underspecified and ambiguous. I have no idea what future formats will be, however since no-one's managed to sort it out in 8(?) years of work and polls on the list have indicated that no-one's really interested in sorting it out (see e.g. the discussion over what the X.509 sig format is from a while back), I don't hold out much hope. Since everything except ssh-rsa has had to be removed over time because no-one's sure of the format for signatures, requiring that people use the existing universally-implemented ssh-rsa signatures with all of the removed formats would solve this problem. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 07:36:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11285 for ; Wed, 23 Feb 2005 07:36:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DF1CC519E; Wed, 23 Feb 2005 12:36:14 +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 46A72516C for ; Wed, 23 Feb 2005 12:36:13 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D3vkS-0004Ha-00 for ietf-ssh@netbsd.org; Wed, 23 Feb 2005 12:36:12 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Wed, 23 Feb 2005 12:36:12 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >Ben Harris writes: >>Imagine I've got an RSA-based authentication system, with its own certificate >>format, so I define a wibble-rsa@bjh21.me.uk public-key format. It happens >>that my authentication system uses its keys with RSASSA-PSS internally. >> >>1: Am I required to use the "ssh-rsa" signature format? > >No, you can use whatever you want, although unless you use ssh-rsa you're not >going to be able to talk to anything else (obviously, that's what's implied >by the xyz@foo.com format). In that case, I don't think I have any objection to your proposal, though I still think a better approach at this stage would be to simply remove all mention of OpenPGP keys and leave their handling to be defined properly in a separate RFC. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 08:12:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13937 for ; Wed, 23 Feb 2005 08:12:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 30EB452BE; Wed, 23 Feb 2005 13:12:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id 01C83524C for ; Wed, 23 Feb 2005 13:12:16 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id F1A0334D62; Thu, 24 Feb 2005 02:12:15 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31544-25; Thu, 24 Feb 2005 02:12:15 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id D82E834D45; Thu, 24 Feb 2005 02:12:15 +1300 (NZDT) 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 CF91837743; Thu, 24 Feb 2005 02:12:15 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D3wJU-0003Sa-00; Thu, 24 Feb 2005 02:12:24 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts In-Reply-To: Message-Id: Date: Thu, 24 Feb 2005 02:12:24 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Harris writes: >I still think a better approach at this stage would be to simply remove all >mention of OpenPGP keys and leave their handling to be defined properly in a >separate RFC. In a perfect world I'd agree that this would be the way to do it, however given the lack of interest shown in this in the past I think this would be a kind of de facto consignment to oblivion of all the other formats. The advantage of doing it now would be that it only requires a few words changed here and there, rather than an entire new RFC that (most probably) no-one will ever be motivated to write (just thinking of my own code, it'd take me about 5 minutes to add an "x509-whatever" or "pgp-whatever" entry to the SSH cert decoding table, but a great many hours to do an RFC to specify it). It's a pay-me-now/pay-me-later thing, I'd rather change a sentence or two now than have to do an entire RFC later. The only possible ambiguity I can see with the use of X.509/OpenPGP/SPKI keys is whether you include a single key/cert or throw in an entire WoT/cert chain/whatever bundle, so the text would have to be explicit in saying that only a single key/cert is present, not an arbitrary collection of stuff. I guess if you want to be really picky you could go on for pages and pages about which sort of cert/key attributes need to be present and how to determine whether they're valid for the server being connected to and how to handle revocation checking and let's convene a subcommittee to report back on this in six months, but since the current way of doing it is just a raw public key with no attributes at all, I think a sentence like "Determining whether a key or certificate is valid for its intended purpose is a local configuration issue" would be the best way out. Either that or just drop all foreign formats on grounds of total incomprehensibility and no-one's really interested anyway. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 08:40:47 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16326 for ; Wed, 23 Feb 2005 08:40:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5FFEB52C3; Wed, 23 Feb 2005 13:40: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 5B734516C for ; Wed, 23 Feb 2005 13:40:38 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa14656; 23 Feb 2005 8:40 EST Date: Wed, 23 Feb 2005 08:40:23 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts Message-ID: <375E547485FCA05FCD633757@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:010OKINTpK/akcLQC2A2C4pGdUv2BXFgE9V7aaBmI=; 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, February 24, 2005 02:12:24 AM +1300 Peter Gutmann wrote: > Ben Harris writes: > >> I still think a better approach at this stage would be to simply remove >> all mention of OpenPGP keys and leave their handling to be defined >> properly in a separate RFC. > > In a perfect world I'd agree that this would be the way to do it, however > given the lack of interest shown in this in the past I think this would > be a kind of de facto consignment to oblivion of all the other formats. > The advantage of doing it now would be that it only requires a few words > changed here and there, rather than an entire new RFC that (most > probably) no-one will ever be motivated to write (just thinking of my own > code, it'd take me about 5 minutes to add an "x509-whatever" or > "pgp-whatever" entry to the SSH cert decoding table, but a great many > hours to do an RFC to specify it). It's a pay-me-now/pay-me-later thing, > I'd rather change a sentence or two now than have to do an entire RFC > later. > Either that or just drop all foreign formats on grounds of total > incomprehensibility and no-one's really interested anyway. Ah, now you have the right idea. If no one cares enough about these to write up clear, unambiguous specs that spell out all the details required for secure, interoperable implementations, I can't imagine why anyone would care enough to actually implement and test them. If we don't have two interoperable implementations of these key types, they will have to be dropped before we can move to draft. If we don't believe there are ever going to be two interoperable implementations, we might as well drop them _now_, and save all the nastiness about how massively underspecified they are. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Feb 23 10:36:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29091 for ; Wed, 23 Feb 2005 10:36:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6BA15539F; Wed, 23 Feb 2005 15:34:48 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cgi03.plus.net (cgi03.plus.net [195.166.130.160]) by mail.netbsd.org (Postfix) with ESMTP id E1208517F for ; Wed, 23 Feb 2005 15:34:46 +0000 (UTC) Received: from wwwuser by cgi03.plus.net with local (Exim 4.31; FreeBSD) id 1D3yXG-000LQQ-7t for ietf-ssh@netbsd.org; Wed, 23 Feb 2005 15:34:46 +0000 To: ietf-ssh@NetBSD.org Subject: I send to you password and login very secret From: "Hacker M." Reply-To: Hacker@underworld.net MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Wed, 23 Feb 2005 15:34:46 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Login:JamEs693 Password:UjlKi6814JbG2 Address: http://nesiparink.tik.lt Send me 50000$ next week ok? reply me Bye, your private hacer From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Feb 24 06:46:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05040 for ; Thu, 24 Feb 2005 06:46:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 55D5F53C8; Thu, 24 Feb 2005 11:46:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 254C853C3 for ; Thu, 24 Feb 2005 11:46:32 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 7D6FC1B8026; Thu, 24 Feb 2005 12:46:15 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 24209-01-25; Thu, 24 Feb 2005 12:46:05 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 978EA1B801D; Thu, 24 Feb 2005 12:46:05 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j1OBk4Xa022336; Thu, 24 Feb 2005 12:46:05 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j1OBjtB6022333; Thu, 24 Feb 2005 12:45:55 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: bjh21@bjh21.me.uk, ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 24 Feb 2005 12:45:54 +0100 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > The only possible ambiguity I can see with the use of X.509/OpenPGP/SPKI keys > is whether you include a single key/cert or throw in an entire WoT/cert > chain/whatever bundle, so the text would have to be explicit in saying that > only a single key/cert is present, not an arbitrary collection of > stuff. At least for spki, that doesn't make much sense. The model is that the server uses only a flat acl list (analogous to "root cert list" for x.509), and it's the client's responsibility to provide whatever certificates are needed to prove that it is authorized. And the colection shouldn't be arbitrary either, it should provide precisely the information needed, and in the right order, for the spki machinery to derive the authorization for the given key. Back to signature formats, I think one reason it makes sense to use an ssh-specific format for all signatures, is that certificate standards tend to focus on the certificates, and about the only signatures that are specified in detail are signatures on certificate. How a certified key is to be used by applications is left open, since all applications but signing other certificates are irrelevant to interoperability in the creation and verification of the certificates. By using ssh-rsa and ssh-dss signature formats (and also spelling out precisely which data should be signed), we say how certified keys are to be used in our application, ssh. /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 25 09:16:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18540 for ; Fri, 25 Feb 2005 09:16:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 11A6D5322; Fri, 25 Feb 2005 14:16:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id CC481518A for ; Fri, 25 Feb 2005 14:16:18 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2005 07:31:10 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107734400"; d="scan'208"; a="229215732:sNHT24478936" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1PEGBq8021388; Fri, 25 Feb 2005 06:16:12 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA03589; Fri, 25 Feb 2005 06:16:15 -0800 (PST) Date: Fri, 25 Feb 2005 06:16:15 -0800 (PST) From: Chris Lonvick To: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: Nits in current drafts In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Sun, 20 Feb 2005, Ben Harris wrote: > I've mentioned some of these before, Sorry, I must have missed them. > but all of them still apply to the > set of drafts released on Friday. > > draft-ietf-secsh-transport-23.txt: > > Section 6.4: replace "The hash algorithms are described in [SCHNEIER]." > with "The SHA-1 hash algorithm is described in [FIPS-180-2]. The MD5 hash > algorithm is described in [RFC1321]." OK. > > Section 6.6: replace each occurrence of "the SHA-1 hash" with "the SHA-1 > hash, as defined in [FIPS-180-2],". Like Sam says, the first occurance should be sufficient. > > Section 6.6: replace "according to [SCHNEIER] and [RFC3447]" with > "according to the RSASSA-PKCS1-v1_5 scheme of [RFC3447]". OK. > > Sections 8.1, 8.2: replace each occurrence of "SHA-1" with "SHA-1, as > defined in [FIPS-180-2],". > > Section 15.1: delete references [RFC2693] and [RFC3280]. Good catch. > > Section 15.1: add references: > > > > The MD5 Message-Digest Algorithm > > > > > > > The references for RFCs are already done. http://xml.resource.org/public/rfc/bibxml/ I just have to pull that (actually just the tar) and then give an "include" in the document. > > > > Secure Hash Standard (SHS) > > National Institute of Standards and Technology > (NIST) > > > > > Unlike the RFCs, there are not too many FIPS pubs in the repository http://xml.resource.org/public/rfc/bibxml2/ > > The references to other FIPS PUBs could do with all having the same > format and being in numerical order. I'd suggest replacing them with: OK. > > > > Data Encryption Standard (DES) > > National Institute of Standards and Technology > (NIST) > > > > > I think the seriesInfo should be spelled out: Data Encryption Standard (DES) National Institute of Standards and Technology and I'll make them all consistent. > > > > Digital Signature Standard (DSS) > > National Institute of Standards and Technology > (NIST) > > > > > > > > > Advanced Encryption Standard (AES) > > National Institute of Standards and Technology > (NIST) > > > > > > > draft-ietf-secsh-connect-24.txt: > > Section 5.2: replace second paragraph with: > > After receiving this message, the recipient MAY send the given number > of bytes more than it was previously allowed to send; the window size > is incremented. Implementations MUST correctly handle window sizes of > up to 2^32 - 1 bytes. The window MUST NOT be increased above 2^32 - 1 > bytes. > OK. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Feb 25 09:18:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18852 for ; Fri, 25 Feb 2005 09:18:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 14C4B5303; Fri, 25 Feb 2005 14:18:01 +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 931EC518A for ; Fri, 25 Feb 2005 14:17:59 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2005 06:29:49 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1PEHtuC021134 for ; Fri, 25 Feb 2005 06:17:55 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA04849 for ; Fri, 25 Feb 2005 06:17:57 -0800 (PST) Date: Fri, 25 Feb 2005 06:17:57 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: signature formats Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, The discussion of signature formats (in the "Nits in current drafts" thread) meandered a bit and I'm not sure that I saw clear consensus on what if any changes need to be made in the core IDs. Can we wrap this up? There was a proposal to remove the "pgp-sign-*" formats as they are underspecified in [TRANS]. Does anyone disagree with doing this? Are there any other changes that are needed in the IDs to close this issue? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Feb 26 16:32:58 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02827 for ; Sat, 26 Feb 2005 16:32:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4956D5462; Sat, 26 Feb 2005 21:32:45 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by mail.netbsd.org (Postfix) with ESMTP id B9B92515B for ; Sat, 26 Feb 2005 21:32:43 +0000 (UTC) Received: by luminous.mit.edu (Postfix, from userid 1000) id 4EC4D76E4B; Sat, 26 Feb 2005 16:32:36 -0500 (EST) To: Chris Lonvick Cc: ietf-ssh@NetBSD.org, housley@vigilsec.com Subject: Re: signature formats References: From: Sam Hartman Date: Sat, 26 Feb 2005 16:32:36 -0500 In-Reply-To: (Chris Lonvick's message of "Fri, 25 Feb 2005 06:17:57 -0800 (PST)") Message-ID: <87oee7gg7f.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Chris" == Chris Lonvick writes: Chris> Hi, The discussion of signature formats (in the "Nits in Chris> current drafts" thread) meandered a bit and I'm not sure Chris> that I saw clear consensus on what if any changes need to Chris> be made in the core IDs. Can we wrap this up? My request as AD for the group is that if you do any more than this, you get explicit buy-in from Russ as document shepherd. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 28 06:42:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08503 for ; Mon, 28 Feb 2005 06:42:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E7875290; Mon, 28 Feb 2005 11:41:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mail.netbsd.org (Postfix) with ESMTP id EF5E1515B for ; Mon, 28 Feb 2005 11:41:53 +0000 (UTC) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1SBbnHn022597 for ; Mon, 28 Feb 2005 22:37:49 +1100 Received: from [202.7.85.66] (b1042.static.pacific.net.au [202.7.85.66]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1SBbmS4015197 for ; Mon, 28 Feb 2005 22:37:48 +1100 Message-ID: <4223025C.7000208@perme8.com> Date: Mon, 28 Feb 2005 22:37:00 +1100 From: "peterg@perme8.com" Reply-To: peterg@perme8.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: re: http://www.openssh.org/manual.html Here's the new URL's for the latest revisions of the IETF ssh drafts... 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 re: http://www.openssh.org/manual.html Here's the new URL's for the latest revisions (17 Feb 2005) of the IETF ssh drafts... ._____ your website copy of the ssh architecture draft is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-architecture-12.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-21.txt ._____ your website copy of the ssh transport layer protocol is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-transport-14.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-23.txt ._____ your website copy of the ssh user authentication layer draft is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-userauth-15.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-26.txt ._____ your website copy of the ssh connection layer protocol is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-connect-15.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt ...pete From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Feb 28 06:43:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08678 for ; Mon, 28 Feb 2005 06:43:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1F8FD5387; Mon, 28 Feb 2005 11:43:20 +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 E6882515B for ; Mon, 28 Feb 2005 11:43:17 +0000 (UTC) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1SBa1A6024027 for ; Mon, 28 Feb 2005 22:36:01 +1100 Received: from [202.7.85.66] (b1042.static.pacific.net.au [202.7.85.66]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1SBa1S4014903 for ; Mon, 28 Feb 2005 22:36:01 +1100 Message-ID: <422301F0.7010406@zipworld.com.au> Date: Mon, 28 Feb 2005 22:35:12 +1100 From: "concnow@zipworld.com.au" Reply-To: concnow@zipworld.com.au User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: re: http://www.openssh.org/manual.html Here's the new URL's for the latest revisions of the IETF ssh drafts... 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 re: http://www.openssh.org/manual.html Here's the new URL's for the latest revisions (17 Feb 2005) of the IETF ssh drafts... ._____ your website copy of the ssh architecture draft is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-architecture-12.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-21.txt ._____ your website copy of the ssh transport layer protocol is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-transport-14.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-23.txt ._____ your website copy of the ssh user authentication layer draft is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-userauth-15.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-26.txt ._____ your website copy of the ssh connection layer protocol is outdated. Ie: http://www.openssh.org/txt/draft-ietf-secsh-connect-15.txt is outdated. You can get the updated (much better layout) and latest revision of the architecture draft (17 Feb 2005) at: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt