From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 10:34:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyAK-00063h-H3 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 10:34:56 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyAH-000279-I9 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 10:34:56 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id AD39363B16A; Wed, 7 Mar 2007 15:34:41 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id C85EE63B165 for ; Wed, 7 Mar 2007 15:34:40 +0000 (UTC) Received: from [192.168.1.62] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 1378978; Wed, 07 Mar 2007 08:35:08 -0700 Message-ID: <45EEDB8C.8010606@vandyke.com> Date: Wed, 07 Mar 2007 08:34:36 -0700 From: Joseph Galbraith User-Agent: Thunderbird 2.0b1 (Windows/20061209) MIME-Version: 1.0 To: Ben Harris CC: ietf-ssh@NetBSD.org Subject: Re: draft-bjh21-ssh-transport-extension-01 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Ben Harris wrote: > I've uploaded a new version of my transport extension draft which I > think addresses everyone's comments. Any more before I wave it at the > IESG? In particular, I'm wondering if I should extend it to allocate > similar message numbers for extensions to ssh-userauth and/or > ssh-connect. > > I just read this through with an eye towards implementing it, and have several comments: 1. Did I just miss it, or is the message number actually not yet defined? 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't reasonably possible to identify which packet was unimplemented.) For unrecognized extensions, I'd rather see a predefined extension: byte SSH_MSG_TRANSPORT_EXTENSION string "unrecognized-extension" that should be sent in response to a extension the implementation doesn't recognize. This has the advantage that the sender can differentiate between implementations not implementing the draft and implementations not implementing the extension. 3. Do we need a nod to in-order vs. out-of-order processing: Much of the SSH protocol allows multiple requests to be made before receiving a response. For any given extension requiring a response, the extension MUST define whether multiple outstanding requests are to be allowed, and if so, whether there are constraints on the ordering of the processing and responses. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 10:49:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyO2-0002Zl-D2 for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 10:49:06 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyNz-0003YY-Fi for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 10:49:06 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id A6D7A63B1A2; Wed, 7 Mar 2007 15:48:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121]) by mail.netbsd.org (Postfix) with ESMTP id 8770663B197 for ; Wed, 7 Mar 2007 15:48:58 +0000 (UTC) Received: from simon by ixion.tartarus.org with local (Exim 3.36 #1 (Debian)) id 1HOyNl-0006GJ-00; Wed, 07 Mar 2007 15:48:49 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <45EEDB8C.8010606@vandyke.com> Subject: Re: draft-bjh21-ssh-transport-extension-01 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 07 Mar 2007 15:48:49 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Joseph Galbraith wrote: > 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't > reasonably possible to identify which packet was unimplemented.) Why not? You can remember the sequence number when you construct your outgoing packets. I admit I have no first-hand experience of actually trying this, but I'd imagine that there aren't _many_ circumstances under which you can recover from SSH_MSG_UNIMPLEMENTED and continue a useful session. In other words, you'd be able to identify _specific_ outgoing packets on your side of the connection for which you'd be interested in noticing SSH_MSG_UNIMPLEMENTED. Then you can remember the sequence number of each of those specific packets until you receive either the SSH_MSG_UNIMPLEMENTED or the expected response. For any packet for which you _don't_ have a defined SSH_MSG_UNIMPLEMENTED handler, there's nothing you can really do except to terminate the session on the grounds that the other side refused to deal with something you couldn't manage without. -- Simon Tatham "My heart bleeds. (That's how it works.)" -- Gareth Taylor From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 11:11:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyjW-0000ZX-GG for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:11:18 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyjI-0000HP-0L for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:11:18 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id CDB9963B194; Wed, 7 Mar 2007 16:10:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 8DEC663B11C for ; Wed, 7 Mar 2007 16:10:58 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA05584; Wed, 7 Mar 2007 11:10:57 -0500 (EST) From: der Mouse Message-Id: <200703071610.LAA05584@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 7 Mar 2007 11:09:40 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: draft-bjh21-ssh-transport-extension-01 In-Reply-To: <45EEDB8C.8010606@vandyke.com> References: <45EEDB8C.8010606@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't > reasonably possible to identify which packet was unimplemented.) This is no worse than the stock protocol with respect to channel requests. > [...] > This has the advantage that the sender can differentiate between > implementations not implementing the draft and implementations not > implementing the extension. Why would a sender care? I'm having trouble thinking of a reason. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 11:22:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyfQ-0007Zl-7D for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:07:04 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOycQ-0006kc-8a for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:04:25 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 3153763B141; Wed, 7 Mar 2007 16:03:26 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with ESMTP id 823B663B197 for ; Wed, 7 Mar 2007 16:03:24 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l27G3Ea3025868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 11:03:19 -0500 (EST) Date: Wed, 07 Mar 2007 11:03:14 -0500 From: Jeffrey Hutzelman To: Joseph Galbraith , Ben Harris cc: ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: draft-bjh21-ssh-transport-extension-01 Message-ID: In-Reply-To: <45EEDB8C.8010606@vandyke.com> References: <45EEDB8C.8010606@vandyke.com> Originator-Info: login-token=Mulberry:01HMUrSIYtoLxoEKPJT0Nbt7M3YnOj+aSJOlmtUkU=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Wednesday, March 07, 2007 08:34:36 AM -0700 Joseph Galbraith wrote: > Ben Harris wrote: >> I've uploaded a new version of my transport extension draft which I >> think addresses everyone's comments. Any more before I wave it at the >> IESG? In particular, I'm wondering if I should extend it to allocate >> similar message numbers for extensions to ssh-userauth and/or >> ssh-connect. >> >> > -01.txt> > > I just read this through with an eye towards implementing it, > and have several comments: > > 1. Did I just miss it, or is the message number actually not yet > defined? No, you didn't miss it. The actual message number won't be assigned by IANA until after the spec has been approved by the IESG. This is normal for assignments requiring IESG approval and/or IETF consensus action. > 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't > reasonably possible to identify which packet was unimplemented.) > > For unrecognized extensions, I'd rather see a predefined > extension: > > byte SSH_MSG_TRANSPORT_EXTENSION > string "unrecognized-extension" > > that should be sent in response to a extension the implementation > doesn't recognize. > > This has the advantage that the sender can differentiate between > implementations not implementing the draft and implementations > not implementing the extension. I'm not sure whether this is necessary, but if it is, then it's likely also necessary to indicate _which_ extension was unexported. > 3. Do we need a nod to in-order vs. out-of-order processing: Yes, that's probably a good idea. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 11:29:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOz14-0006lD-KF for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:29:27 -0500 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOz13-0000Vc-6Y for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:29:26 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 7ABA863B11F; Wed, 7 Mar 2007 16:29:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id B2E6163B171 for ; Wed, 7 Mar 2007 16:29:12 +0000 (UTC) Received: from [192.168.1.62] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 1379354; Wed, 07 Mar 2007 09:29:41 -0700 Message-ID: <45EEE857.2090506@vandyke.com> Date: Wed, 07 Mar 2007 09:29:11 -0700 From: Joseph Galbraith User-Agent: Thunderbird 2.0b1 (Windows/20061209) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: draft-bjh21-ssh-transport-extension-01 References: <45EEDB8C.8010606@vandyke.com> <200703071610.LAA05584@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200703071610.LAA05584@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab der Mouse wrote: >> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't >> reasonably possible to identify which packet was unimplemented.) > > This is no worse than the stock protocol with respect to channel > requests. > >> [...] >> This has the advantage that the sender can differentiate between >> implementations not implementing the draft and implementations not >> implementing the extension. > > Why would a sender care? I'm having trouble thinking of a reason. Well, the use case that comes to my mind is that if the draft isn't implemented, the sender might which to avoid sending any further extensions, but if it is just a specific extension, the sender might care to use other extensions. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 11:52:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOzNe-0001tr-9R for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:52:46 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOzNb-00083k-Aa for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 11:52:46 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id EEF1B63B1F7; Wed, 7 Mar 2007 16:17:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 3998E63B1D6 for ; Wed, 7 Mar 2007 16:17:46 +0000 (UTC) Received: from [192.168.1.62] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 1379275; Wed, 07 Mar 2007 09:18:14 -0700 Message-ID: <45EEE5A6.7050605@vandyke.com> Date: Wed, 07 Mar 2007 09:17:42 -0700 From: Joseph Galbraith User-Agent: Thunderbird 2.0b1 (Windows/20061209) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: draft-bjh21-ssh-transport-extension-01 References: <45EEDB8C.8010606@vandyke.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Jeffrey Hutzelman wrote: > > > On Wednesday, March 07, 2007 08:34:36 AM -0700 Joseph Galbraith > wrote: > >> Ben Harris wrote: >>> I've uploaded a new version of my transport extension draft which I >>> think addresses everyone's comments. Any more before I wave it at the >>> IESG? In particular, I'm wondering if I should extend it to allocate >>> similar message numbers for extensions to ssh-userauth and/or >>> ssh-connect. >>> >>> >> -01.txt> >> >> I just read this through with an eye towards implementing it, >> and have several comments: >> >> 1. Did I just miss it, or is the message number actually not yet >> defined? > > No, you didn't miss it. The actual message number won't be assigned by > IANA until after the spec has been approved by the IESG. This is normal > for assignments requiring IESG approval and/or IETF consensus action. Ahh... I suspected something like that, but wanted to make sure. >> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't >> reasonably possible to identify which packet was unimplemented.) >> >> For unrecognized extensions, I'd rather see a predefined >> extension: >> >> byte SSH_MSG_TRANSPORT_EXTENSION >> string "unrecognized-extension" >> >> that should be sent in response to a extension the implementation >> doesn't recognize. >> >> This has the advantage that the sender can differentiate between >> implementations not implementing the draft and implementations >> not implementing the extension. > > I'm not sure whether this is necessary, but if it is, then it's likely > also necessary to indicate _which_ extension was unexported. Yes, I was just realizing that my proposal was insufficient for what I wanted. byte SSH_MSG_TRANSPORT_EXTENSION string "unrecognized-extension" string the-unrecognized-extension I do realize that it is possible to track the sequence numbers of suspect outgoing packets (as suggested by Simon in a separate email) but I wasn't considering that an reasonable mechanism, for a couple of reasons: A. We can do better-- rather than forcing tracking, we can simply tell the requester what extension was not recognized. B. Forcing tracking might preclude some uses for the extension, where either numerous packets need to be sent or the time-to-live of a request is not well defined, or is extra-ordinarily long. I'm sure that these problems could be worked around... but why not just avoid the problem? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 07 12:48:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP0FJ-0007l9-FL for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 12:48:13 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP0DV-00037E-2A for secsh-tyoxbijeg7-archive@lists.ietf.org; Wed, 07 Mar 2007 12:46:23 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id D1BE063B242; Wed, 7 Mar 2007 17:45:50 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by mail.netbsd.org (Postfix) with ESMTP id D6CD763B23F for ; Wed, 7 Mar 2007 17:45:49 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from smaug.linux.pwf.cam.ac.uk ([193.60.95.72]:36970) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1HOyzw-0004YX-Ms (Exim 4.63) (return-path ); Wed, 07 Mar 2007 16:28:16 +0000 Received: from bjh21 (helo=localhost) by smaug.linux.pwf.cam.ac.uk with local-esmtp (Exim 4.22) id 1HOyzv-0000is-VS; Wed, 07 Mar 2007 16:28:15 +0000 Date: Wed, 7 Mar 2007 16:28:15 +0000 (GMT) From: Ben Harris To: Joseph Galbraith cc: ietf-ssh@NetBSD.org Subject: Re: draft-bjh21-ssh-transport-extension-01 In-Reply-To: <45EEDB8C.8010606@vandyke.com> Message-ID: References: <45EEDB8C.8010606@vandyke.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.6 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Wed, 7 Mar 2007, Joseph Galbraith wrote: > 3. Do we need a nod to in-order vs. out-of-order processing: I don't think so, for the same reason that I dropped the security consideration about packets sent before SSH_MSG_NEWKEYS: the issue applies to all extensions that define new message types, whether they do it by assigning a whole message number or by using a named message. It would be perverse to impose a more stringent requirement on named messages than on numbered ones. On your other points, Simon's and der Mouse's replies cover everything I was going to say. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 12 21:32:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQvsi-00043I-OJ for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 12 Mar 2007 21:32:52 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQvse-0008TK-61 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 12 Mar 2007 21:32:52 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 970EF63B277; Tue, 13 Mar 2007 01:32:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by mail.netbsd.org (Postfix) with ESMTP id B4BEF63B25F for ; Tue, 13 Mar 2007 01:32:32 +0000 (UTC) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l2CNtEkD023421; Mon, 12 Mar 2007 15:55:14 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l2CNtE7B023420; Mon, 12 Mar 2007 16:55:14 -0700 Date: Mon, 12 Mar 2007 16:55:14 -0700 Message-Id: <200703122355.l2CNtE7B023420@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4819 on Secure Shell Public Key Subsystem From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ssh@netbsd.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 A new Request for Comments is now available in online RFC libraries. RFC 4819 Title: Secure Shell Public Key Subsystem Author: J. Galbraith, J. Van Dyke, J. Bright Status: Standards Track Date: March 2007 Mailbox: galb@vandyke.com, jpv@vandyke.com, jon@siliconcircus.com Pages: 17 Characters: 32794 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-publickey-subsystem-08.txt URL: http://www.rfc-editor.org/rfc/rfc4819.txt Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS TRACK] This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 13 02:43:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR0jO-0001hH-SV for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 13 Mar 2007 02:43:34 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR0jM-0007bt-1W for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 13 Mar 2007 02:43:34 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 8A87063B131; Tue, 13 Mar 2007 06:43:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.10.123]) by mail.netbsd.org (Postfix) with ESMTP id 89F8F63B204 for ; Tue, 13 Mar 2007 06:43:18 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A0AF9C319; Tue, 13 Mar 2007 18:37:30 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ07WVTQq3e1; Tue, 13 Mar 2007 18:37:30 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 13C5B9C2F9; Tue, 13 Mar 2007 18:37:06 +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 A0D8F514010; Tue, 13 Mar 2007 18:37:04 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HQzh8-0002Sd-00; Tue, 13 Mar 2007 18:37:10 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@netbsd.org, , oskari@saarenmaa.fi Subject: Re: X.509 Message-Id: Date: Tue, 13 Mar 2007 18:37:10 +1300 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Oskari Saarenmaa writes: >I recently submitted a new individual draft for ssh x509 which backs down >from what we specified in the latest WG draft, and just specifies how we use >certificates in our implementations. It's available at >http://tools.ietf.org/wg/secsh/draft-saarenmaa-ssh-x509-00.txt > >Any thoughts? Further to my previous comments, the text in the Implementation Considerations section seems a bit misplaced. Firstly, it's already subsumed by the "refer to PKI standards" requirement in the Security Considerations, so it's redundant. Secondly, I would both hope that any implementation that doesn't implement a verification algorithm would fail to verify the certificate that uses it, and can't really see why this would be singled out for special attention when there are lots of other things that also need to be checked. Finally, to be nit-picky, you need to verify up to a trust anchor, which isn't necessarily "all the certificates in the chain". For all of the above, the appropriate solution seems to be to remove this section, since it's already more than covered by the requirement in section 7. Is anyone running a test SSH server that implements this authentication mechanism? I'd like to have something to test against... Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 27 20:50:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWMMi-0007NF-Rs for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 27 Mar 2007 20:50:17 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWMMY-0002e8-6c for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 27 Mar 2007 20:50:16 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id D493763B2C5; Wed, 28 Mar 2007 00:49:53 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from filter2.host.bg (filter2.host.bg [87.120.40.156]) by mail.netbsd.org (Postfix) with ESMTP id 7036063B23F for ; Wed, 28 Mar 2007 00:49:51 +0000 (UTC) Received: from mail.host.bg (mail.host.bg [87.120.40.3]) by filter2.host.bg (Postfix) with ESMTP id 58D086EEEC; Wed, 28 Mar 2007 01:51:26 +0300 (EEST) Received: from [85.130.38.241] (85-130-38-241.1699525.ddns.cablebg.net [85.130.38.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.host.bg (Postfix) with ESMTP id B476A57DE6; Wed, 28 Mar 2007 01:51:25 +0300 (EEST) Message-ID: <460991DD.3030004@roumenpetrov.info> Date: Wed, 28 Mar 2007 00:51:25 +0300 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070306 SeaMonkey/1.0.8 MIME-Version: 1.0 To: Peter Gutmann CC: ietf-ssh@netbsd.org, oskari@saarenmaa.fi Subject: Re: X.509 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Peter Gutmann wrote: > Oskari Saarenmaa writes: > > >> I recently submitted a new individual draft for ssh x509 which backs down >> > >from what we specified in the latest WG draft, and just specifies how we use > >> certificates in our implementations. It's available at >> http://tools.ietf.org/wg/secsh/draft-saarenmaa-ssh-x509-00.txt >> >> Any thoughts? >> > > Further to my previous comments, the text in the Implementation Considerations > section seems a bit misplaced. Firstly, it's already subsumed by the "refer > to PKI standards" requirement in the Security Considerations, so it's > redundant. Secondly, I would both hope that any implementation that doesn't > implement a verification algorithm would fail to verify the certificate that > uses it, and can't really see why this would be singled out for special > attention when there are lots of other things that also need to be checked. > It is possible simple implementation to compare public key extracted from certificate sent with keys from its configuration and if they match to accept connection. As example without this self-issued(self-signed) X.509 certificates cannot be used in authentication. > Finally, to be nit-picky, you need to verify up to a trust anchor, which isn't > necessarily "all the certificates in the chain". > Yes verification should be described in RFC3280. Only the direction is opposite - valid path (chain) start from trust anchor . > For all of the above, the appropriate solution seems to be to remove this > section, since it's already more than covered by the requirement in section 7. > > Is anyone running a test SSH server that implements this authentication > mechanism? I'd like to have something to test against... > > Peter. > You can test my implementation based on openssh and diff files on http://roumenpetrov.info/openssh/download.html . Check the options X509KeyAlgorithm and may be KeyAllowSelfIssued. The configuration like this: X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1,ssh-rsa X509KeyAlgorithm x509v3-sign-dss,dss-raw,ssh-dss , should be in conformance with draft. The configuration: X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1 X509KeyAlgorithm x509v3-sign-dss,dss-raw , should be used with ssh.com, f-secure.com (etc. ?) . I think that ssh.com and f-secure.com will accept md5 hash (rsa based cert.), but not in default configuration. The default is compatible with openssh, vandyke.com (etc. ?) . Roumen From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 31 13:53:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXhlu-0001zd-Oz for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 31 Mar 2007 13:53:50 -0400 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXhlo-0002YP-QX for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 31 Mar 2007 13:53:50 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id E0F6263B3CE; Sat, 31 Mar 2007 17:53:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.10.121]) by mail.netbsd.org (Postfix) with ESMTP id C1C4B63B12D for ; Sat, 31 Mar 2007 17:53:25 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 189C4480533; Sun, 1 Apr 2007 03:56:25 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTvuXFCQdCdv; Sun, 1 Apr 2007 03:56:24 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EED6448052E; Sun, 1 Apr 2007 03:56:24 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 20380514012; Sun, 1 Apr 2007 03:56:21 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HXfwN-0004Ar-00; Sun, 01 Apr 2007 03:56:31 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: openssh@roumenpetrov.info, pgut001@cs.auckland.ac.nz Subject: Re: X.509 Cc: ietf-ssh@netbsd.org, oskari@saarenmaa.fi In-Reply-To: <460991DD.3030004@roumenpetrov.info> Message-Id: Date: Sun, 01 Apr 2007 03:56:31 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 1.0 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Roumen Petrov writes: >Peter Gutmann wrote: >> Further to my previous comments, the text in the Implementation Considerations >> section seems a bit misplaced. Firstly, it's already subsumed by the "refer >> to PKI standards" requirement in the Security Considerations, so it's >> redundant. Secondly, I would both hope that any implementation that doesn't >> implement a verification algorithm would fail to verify the certificate that >> uses it, and can't really see why this would be singled out for special >> attention when there are lots of other things that also need to be checked. > >It is possible simple implementation to compare public key extracted from >certificate sent with keys from its configuration and if they match to accept >connection. Sure, but that's a specific local policy issue, there are (literally) a million other ways to do this and I'm not sure why the RFC draft is choosing to focus on this one particular issue. >>Finally, to be nit-picky, you need to verify up to a trust anchor, which >>isn't necessarily "all the certificates in the chain". > >Yes verification should be described in RFC3280. Only the direction is >opposite - valid path (chain) start from trust anchor . Only if you've swallowed the spaghetti-PKI red-pill lunacy that path construction is top-down, which means you have to solve an NP-hard graph theory problem to verify your cert(s) (at one PKI talk, a top-down path- construction advocate described, with a totally straight face, how his path- construction software had run for three days without terminating, until he killed the process). >You can test my implementation based on openssh and diff files on >http://roumenpetrov.info/openssh/download.html . Thanks. Peter.