From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Oct 4 13:46:10 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDFB3A6897 for ; Sun, 4 Oct 2009 13:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQjVR9EWB7+r for ; Sun, 4 Oct 2009 13:46:10 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E0BEC3A6405 for ; Sun, 4 Oct 2009 13:46:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E651363B293; Sun, 4 Oct 2009 20:47:34 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2]) by mail.netbsd.org (Postfix) with ESMTP id 8352263B28C for ; Sun, 4 Oct 2009 20:47:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dfw0.icgmedia.com (Postfix) with ESMTP id D621617229 for ; Sun, 4 Oct 2009 14:31:57 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at icgmedia.com Received: from dfw0.icgmedia.com ([127.0.0.1]) by localhost (dfw0.icgmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhcqbxUPPrSc for ; Sun, 4 Oct 2009 14:31:53 -0500 (CDT) Received: from titania.braingia.org (66-190-11-170.dhcp.stpt.wi.charter.com [66.190.11.170]) by dfw0.icgmedia.com (Postfix) with ESMTP id 0CB8E16F91 for ; Sun, 4 Oct 2009 14:31:53 -0500 (CDT) Received: by titania.braingia.org (Postfix, from userid 1000) id 074C0A2007; Sun, 4 Oct 2009 14:31:51 -0500 (CDT) Date: Sun, 4 Oct 2009 14:31:51 -0500 From: Steve Suehring To: ietf-ssh@netbsd.org Subject: URI Draft Message-ID: <20091004193151.GA18458@braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hello, I've received a question about the status of the ssh URI draft. I'd like to take this up again but now that the secsh WG is closed, what's the proper procedure for moving the ssh URI draft forward? Here are a couple relevant links from when it was last left: http://osdir.com/ml/ietf.secsh/2006-08/msg00000.html http://osdir.com/ml/ietf.secsh/2006-08/msg00001.html Can this be submitted as an individual submission or is there a WG chair that might take this under their area? Steve From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Oct 4 21:21:28 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAFF3A6970 for ; Sun, 4 Oct 2009 21:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE85Jj6W48qG for ; Sun, 4 Oct 2009 21:21:27 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 792263A681D for ; Sun, 4 Oct 2009 21:21:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1841763B20C; Mon, 5 Oct 2009 04:22:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-6.cisco.com", Issuer "Cisco SSCA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 3513263B13C for ; Mon, 5 Oct 2009 04:22:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1516; q=dns/txt; s=sjiport06001; t=1254716570; x=1255926170; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20RE:=20URI=20Draft|Date:=20Sun,=204=20Oc t=202009=2021:22:47=20-0700|Message-ID:=20 |To:=20"Steve=20Suehring"=20,=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<20091004193151.GA18458@braingia.org> |References:=20<20091004193151.GA18458@braingia.org>; bh=hsg9IcMwLKNcP8DmVxXlinCxwp3/1CsnDFAKRxTj1Nw=; b=alKgdX7uUrUQFkRlyz2qqhy0/yzByFeJlG34byrvr/2dgJB58TYsX3fx nTn8EQzpF/ydw9wkOeSpLyaR5wjNECThHZpgCzldLq33zJHu0Z37K/Y4R gB5GM9JgDZmAM+yPcQFAabKOdOHTvDlmVgo/AUztdg9OZBqRpdA48EMdE A=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=jsalowey@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAoRyUqrR7MV/2dsb2JhbAC5OohhAY1HBoIrgX8 X-IronPort-AV: E=Sophos;i="4.44,504,1249257600"; d="scan'208";a="402020638" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Oct 2009 04:22:49 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n954MnVw018308; Sun, 4 Oct 2009 21:22:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n954MnEp028581; Mon, 5 Oct 2009 04:22:49 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 21:22:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: URI Draft Date: Sun, 4 Oct 2009 21:22:47 -0700 Message-ID: In-Reply-To: <20091004193151.GA18458@braingia.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URI Draft Thread-Index: AcpFM/YJr5KC+vHARKyloPsqwyClOwAPgsuw References: <20091004193151.GA18458@braingia.org> From: "Joseph Salowey (jsalowey)" To: "Steve Suehring" , X-OriginalArrivalTime: 05 Oct 2009 04:22:49.0066 (UTC) FILETIME=[7F2C84A0:01CA4573] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1516; t=1254716569; x=1255580569; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20URI=20Draft |Sender:=20; bh=hsg9IcMwLKNcP8DmVxXlinCxwp3/1CsnDFAKRxTj1Nw=; b=jpNLinXoLWhhW+gM77FW0NQsAN/6SQbS+An2VzHhjaPbljLGMnM4hZJvKY hyWCDTAZwpVHHeL1opZvEaxhY4rWIAqaTJuDcfWUAHqY9YyvZDVu/U6KYFly ytMFzxAe+5CdqJ+5Kf8lWZGJYqLYEqaGKNpvxB64LZp29DVWBsWq4=; Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Steve, Good to hear from you. The basic steps would probably be to=20 1) Submit a new draft revision 2) Ask for a review on the SSH list 3) Ask for a review on the URI list 4) request publication as an individual submission For 1), I think we need to decided if we still want to keep SFTP and SCP in the same draft. It would probably be easier to just have SSH and get it published on standards track. If we want to have SCP and SFTP we probably need to go informational. We can do two documents, SSH followed by SCP and SFTP. =20 Once we decide what we think is the right content we can as the security ADs what the appropriate procedure should be. =20 Cheers, Joe > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Steve Suehring > Sent: Sunday, October 04, 2009 12:32 PM > To: ietf-ssh@netbsd.org > Subject: URI Draft >=20 > Hello, >=20 > I've received a question about the status of the ssh URI=20 > draft. I'd like to take this up again but now that the secsh=20 > WG is closed, what's the proper procedure for moving the ssh=20 > URI draft forward? >=20 > Here are a couple relevant links from when it was last left: >=20 > http://osdir.com/ml/ietf.secsh/2006-08/msg00000.html >=20 > http://osdir.com/ml/ietf.secsh/2006-08/msg00001.html >=20 > Can this be submitted as an individual submission or is there=20 > a WG chair that might take this under their area? > =20 > Steve >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 6 12:12:12 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6391C28C21A for ; Tue, 6 Oct 2009 12:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=-1.397, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id felSkA6cHxmo for ; Tue, 6 Oct 2009 12:12:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8CE1728C0F0 for ; Tue, 6 Oct 2009 12:11:59 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 575D363B1E4; Tue, 6 Oct 2009 19:13:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by mail.netbsd.org (Postfix) with ESMTP id D4A4263B1DC for ; Tue, 6 Oct 2009 19:13:25 +0000 (UTC) X-Trace: 255102260/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.179/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.179 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAPsey0o+vGSz/2dsb2JhbABDgmGNVcMYCoIhgX8E X-IronPort-AV: E=Sophos;i="4.44,513,1249254000"; d="scan'208";a="255102260" X-IP-Direction: IN Received: from 1cust179.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.179]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Oct 2009 18:44:43 +0100 Message-ID: <001c01ca46a4$038af660$0601a8c0@allison> Reply-To: "tom.petch" From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , "Steve Suehring" , References: <20091004193151.GA18458@braingia.org> Subject: Re: URI Draft Date: Tue, 6 Oct 2009 12:44:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list inline ----- Original Message ----- From: "Joseph Salowey (jsalowey)" Sent: Monday, October 05, 2009 6:22 AM Subject: RE: URI Draft Hi Steve, Good to hear from you. The basic steps would probably be to 1) Submit a new draft revision 2) Ask for a review on the SSH list 3) Ask for a review on the URI list 4) request publication as an individual submission For 1), I think we need to decided if we still want to keep SFTP and SCP in the same draft. It would probably be easier to just have SSH and get it published on standards track. If we want to have SCP and SFTP we probably need to go informational. We can do two documents, SSH followed by SCP and SFTP. Once we decide what we think is the right content we can as the security ADs what the appropriate procedure should be. Alternatively, ask the Application area ADs; I think that this is more about URIs than about security, and I see URIs being handled by the two Application ADs. Tom Petch Cheers, Joe > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Steve Suehring > Sent: Sunday, October 04, 2009 12:32 PM > To: ietf-ssh@netbsd.org > Subject: URI Draft > > Hello, > > I've received a question about the status of the ssh URI > draft. I'd like to take this up again but now that the secsh > WG is closed, what's the proper procedure for moving the ssh > URI draft forward? > > Here are a couple relevant links from when it was last left: > > http://osdir.com/ml/ietf.secsh/2006-08/msg00000.html > > http://osdir.com/ml/ietf.secsh/2006-08/msg00001.html > > Can this be submitted as an individual submission or is there > a WG chair that might take this under their area? > > Steve From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 6 15:08:14 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F22D3A684E for ; Tue, 6 Oct 2009 15:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKbJ3U4Um1TD for ; Tue, 6 Oct 2009 15:08:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id DAA7B3A67E4 for ; Tue, 6 Oct 2009 15:08:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B56A163B226; Tue, 6 Oct 2009 22:09:43 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2]) by mail.netbsd.org (Postfix) with ESMTP id 45BEE63B21F for ; Tue, 6 Oct 2009 22:09:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dfw0.icgmedia.com (Postfix) with ESMTP id 6CB4B17043; Tue, 6 Oct 2009 17:09:41 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at icgmedia.com Received: from dfw0.icgmedia.com ([127.0.0.1]) by localhost (dfw0.icgmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsUrhpmL4ivV; Tue, 6 Oct 2009 17:09:34 -0500 (CDT) Received: from titania.braingia.org (66-190-11-170.dhcp.stpt.wi.charter.com [66.190.11.170]) by dfw0.icgmedia.com (Postfix) with ESMTP id DFCB916F9B; Tue, 6 Oct 2009 17:09:33 -0500 (CDT) Received: by titania.braingia.org (Postfix, from userid 1000) id 12405A2007; Tue, 6 Oct 2009 17:09:32 -0500 (CDT) Date: Tue, 6 Oct 2009 17:09:32 -0500 From: Steve Suehring To: "tom.petch" Cc: "Joseph Salowey (jsalowey)" , ietf-ssh@netbsd.org Subject: Re: URI Draft Message-ID: <20091006220932.GA32382@braingia.org> Mail-Followup-To: Steve Suehring , "tom.petch" , "Joseph Salowey (jsalowey)" , ietf-ssh@netbsd.org References: <20091004193151.GA18458@braingia.org> <001c01ca46a4$038af660$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01ca46a4$038af660$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Thanks for the feedback Tom. I've sent a revised draft to Joe for his feedback. After that we'll submit it as appropriate here. Steve On Tue, Oct 06, 2009 at 12:44:12PM +0200, tom.petch wrote: > > inline > > > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" > Sent: Monday, October 05, 2009 6:22 AM > Subject: RE: URI Draft > > Hi Steve, > > Good to hear from you. The basic steps would probably be to > > 1) Submit a new draft revision > 2) Ask for a review on the SSH list > 3) Ask for a review on the URI list > 4) request publication as an individual submission > > For 1), I think we need to decided if we still want to keep SFTP and SCP > in the same draft. It would probably be easier to just have SSH and get > it published on standards track. If we want to have SCP and SFTP we > probably need to go informational. We can do two documents, SSH > followed by SCP and SFTP. > > Once we decide what we think is the right content we can as the security > ADs what the appropriate procedure should be. > > > > Alternatively, ask the Application area ADs; I think that this is more about > URIs than about security, and I see URIs being handled by the two Application > ADs. > > Tom Petch > > > Cheers, > > Joe > > > -----Original Message----- > > From: ietf-ssh-owner@NetBSD.org > > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Steve Suehring > > Sent: Sunday, October 04, 2009 12:32 PM > > To: ietf-ssh@netbsd.org > > Subject: URI Draft > > > > Hello, > > > > I've received a question about the status of the ssh URI > > draft. I'd like to take this up again but now that the secsh > > WG is closed, what's the proper procedure for moving the ssh > > URI draft forward? > > > > Here are a couple relevant links from when it was last left: > > > > http://osdir.com/ml/ietf.secsh/2006-08/msg00000.html > > > > http://osdir.com/ml/ietf.secsh/2006-08/msg00001.html > > > > Can this be submitted as an individual submission or is there > > a WG chair that might take this under their area? > > > > Steve From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 8 09:19:16 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A8F28C1B2 for ; Thu, 8 Oct 2009 09:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVvjlz3de3BV for ; Thu, 8 Oct 2009 09:19:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id EB4B028C1B5 for ; Thu, 8 Oct 2009 09:19:03 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CAC8C63B242; Thu, 8 Oct 2009 16:20:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2]) by mail.netbsd.org (Postfix) with ESMTP id 3FC1063B2DA for ; Thu, 8 Oct 2009 16:20:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dfw0.icgmedia.com (Postfix) with ESMTP id CD36D1716F for ; Thu, 8 Oct 2009 11:20:10 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at icgmedia.com Received: from dfw0.icgmedia.com ([127.0.0.1]) by localhost (dfw0.icgmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaqtBUsFAfq2 for ; Thu, 8 Oct 2009 11:20:01 -0500 (CDT) Received: from titania.braingia.org (66-190-11-170.dhcp.stpt.wi.charter.com [66.190.11.170]) by dfw0.icgmedia.com (Postfix) with ESMTP id 02FD716F9B for ; Thu, 8 Oct 2009 11:20:01 -0500 (CDT) Received: by titania.braingia.org (Postfix, from userid 1000) id CF308A2007; Thu, 8 Oct 2009 11:19:56 -0500 (CDT) Date: Thu, 8 Oct 2009 11:19:56 -0500 From: Steve Suehring To: ietf-ssh@netbsd.org Subject: SSH URI Draft Message-ID: <20091008161956.GB10539@braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, Attached is a revised draft of the SSH URI proposal. This draft removes the SCP and SFTP URI sections, adds an example, and updates the status of some of the references as well as changes for new IETF requirements, among other changes. Please let me know any feedback on the draft. After a short period I'll be submitting it to the IETF. Note that this draft is currently named as an individual submission. If we find that it should go within another WG then it may be renamed as appropriate. Here are previous drafts: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/ Steve --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-suehring-sshuri-00.txt" Network Working Group J. Salowey Internet-Draft Cisco Systems Intended Status: Proposed Standard S. Suehring Expires: April 9, 2010 October 6, 2009 Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH) draft-suehring-sshuri-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the Uniform Resource Identifiers used to locate resources for the Secure Shell (SSH) protocol. The document describes the generic syntax involved in URI definitions as well as specific definitions for the protocol. The specific definition may include user credentials such as username and also may include other parameters such as host key fingerprint. In addition, security considerations and examples are also provided within this document. Salowey & Suehring Expires April 9, 2010 [Page 1] Internet-Draft URI Scheme for SSH October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document. . . . . . . . . . . . . . 3 3. General Syntax . . . . . . . . . . . . . . . . . . . . . . . 3 4. Secure Shell (SSH) URI . . . . . . . . . . . . . . . . . . . 3 4.1 Scheme Name . . . . . . . . . . . . . . . . . . . . . . . 3 4.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.3 URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 3 4.4 URI Semantics . . . . . . . . . . . . . . . . . . . . . . 4 4.5 Encoding Considerations . . . . . . . . . . . . . . . . . 4 4.6 Protocols using this URI scheme . . . . . . . . . . . . . 4 4.7 Security Considerations . . . . . . . . . . . . . . . . . 4 4.8 Contact . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 SSH connection parameters . . . . . . . . . . . . . . . . 5 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . .. . . . . . . . . . . . . . . . . . . . . . . 7 10.1 Normative References . .. . . . . . . . . . . . . . . . 7 10.2 Informative References . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . 8 Salowey & Suehring Expires April 9, 2010 [Page 2] Internet-Draft URI Scheme for SSH October 2009 1. Introduction This document describes the Uniform Resource Identifiers (URIs) to be used with the Secure Shell (SSH) [RFC4251] protocol. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. General Syntax A hierarchical URI shall consist of the scheme and the scheme specific portion separated by a colon ":" followed by the hierarchical part, as discussed in [RFC3986]. This specification uses the definitions "port", "host", "scheme", "userinfo", "path- empty", "path-abempty" and "authority" from [RFC3986]. This document follows the ABNF notation defined in [RFC5234]. 4. Secure Shell (SSH) URI This section describes the SSH URI and contains the information necessary to register the URI according to the template in [RFC4395]. 4.1 Scheme Name The Secure Shell scheme name is "ssh". 4.2 Status The requested status of the SSH URI is "permanent". 4.3 URI Scheme Syntax The Secure Shell (SSH) scheme shall consist of the scheme name "ssh" followed by a colon ":" followed by hier-part defined in [RFC3986]. The SSH URI ABNF definition follows. sshURI = "ssh:" hier-part hier-part = "//" authority path-abempty authority = [ [ ssh-info ] "@" ] host [ ":" port ] host = port = path-abempty = ssh-info = [ userinfo ] [";" c-param *("," c-param)] userinfo = c-param = paramname "=" paramvalue paramname = *( ALPHA / DIGIT / "-" ) paramvalue = *( ALPHA / DIGIT / "-" ) Salowey & Suehring Expires April 9, 2010 [Page 3] Internet-Draft URI Scheme for SSH October 2009 The following reserved characters from [RFC3986] are used as delimiters within the SSH URI: ";", ",", ":", "=", and "/". They must not be escaped when used as delimiters and must be escaped when the appear in other uses. 4.4 URI Semantics The intended usage of the SSH URI is to establish an interactive SSH terminal session with the host defined in the authority portion of the URI. The only operation defined for the URI is to establish an SSH terminal session with a remote host. If the userinfo or connection parameters are present the at-sign "@" shall precede the authority section of the URI. Optionally, the authority section MAY also include the port preceded by a colon ":". The host SHOULD be a non-empty string. If the port is not included, the default port is assumed. The ssh-info portion of the URI MAY include credentials consisting of a username followed by optional parameters. The convention of including the password separated from the username by a ":" in the URI is NOT RECOMMENDED and is deprecated in accordance with [RFC3986]. One or more optional connection parameters (c-param) may be specified within the userinfo section of the URI. These conn-parameters are separated from the userinfo by a semi-colon ";". The only connection parameter defined in this document is for the host-key fingerprint described in Section 4.1. It is possible that additional parameters be defined in the future. If a connection parameter is not understood it SHOULD be ignored. The SSH URI does not define a usage for a non-empty path element. If a non-empty path element is included in an SSH URI then it SHOULD be ignored. 4.5 Encoding Considerations The encoding of the "host" portion of the URI is as defined in [RFC3986]. The encoding of the connection parameters is described in Section 4.1 4.6 Protocols using this URI scheme This URI scheme is used by the SSH protocol version 2 defined in [RFC4251]. 4.7 Security Considerations See Section 7. Salowey & Suehring Expires April 9, 2010 [Page 4] Internet-Draft URI Scheme for SSH October 2009 4.8 Contact This document is a product of the SSH working group. 5. Parameters 5.1 SSH connection parameters The following parameters are associated with an SSH connection. All parameters are optional and MUST NOT overwrite configured defaults. Individual parameters are separated by a comma (","). fingerprint The fingerprint parameter contains the fingerprint of the host key for the host specified in the URI. The fingerprint is encoded as host-key-alg-fingerprint. Host-key-alg is host public key algorithm defined in [RFC4253] and the fingerprint format is [RFC4716]. For use in a URI, the fingerprint shall use a single dash "-" as a separator instead of the colon ":" as described in [RFC4716]. This parameter MUST NOT overwrite a key that is already configured for the host. The fingerprint MAY be used to validate the authenticity of the host key if the URI was obtained from an authenticated source with its integrity protected. If this parameter is not included then the host key is validated using another method. See Security Considerations section for additional considerations. There MUST be only one fingerprint parameter present in a given URI. 6. Examples The following section shows basic examples of URIs. This section should not be considered to include all possible combinations of URIs for each protocol. An SSH connection to the host host.example.com on the standard port. ssh://host.example.com An SSH connection to the host host.example.com on the standard port using username user. ssh://user@host.example.com An SSH connection to the host host.example.com on port 2222 using username user. ssh://user@host.example.com:2222 An SSH connection to the host having the specified host-key Salowey & Suehring Expires April 9, 2010 [Page 5] Internet-Draft URI Scheme for SSH October 2009 fingerprint at host.example.com on the standard port using username user. ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97- 77-10-d7-46-41-63-87@host.example.com 7. IANA Considerations Section 3 provides the information required in the URI registration template in accordance with [RFC4395]. 8. Security Considerations Passwords SHOULD NOT be included within the URI as doing so poses a security risk. URIs are usually sent in the clear with no encryption or other security, any password or other credentials included in the userinfo could be seen by a potential attacker. Although the host-key fingerprint is not confidential information, care must be taken in handling fingerprints associated with URIs because URIs transmitted or stored without protection may be modified by an attacker. In general an implementation cannot determine the source of a URI so a fingerprint received in a URI should have no more trust associated with it than a raw public key received in the SSH protocol itself. If a locally configured key exists for the server already it MUST NOT be automatically overwritten with information from the URI. If the host is unknown then the implementation should treat the fingerprint received with the same caution that it does with any unknown public key. The client MAY offer the fingerprint and URI for external validation before allowing a connection based on this information. If the client chooses to make a connection based on the URI information and it finds that the fingerprint in the URI and the public key offered by the server do not match then it SHOULD provide a warning and provide a means to abort the connection. Sections 4.1 and 9.2.4 of [RFC4251] provide a good discussion of handling public keys received in the SSH protocol. 9. Acknowledgements Ben Harris, Tom Petch and the members of the SSH working group have provided much useful feedback in the preparation of this document. Salowey & Suehring Expires April 9, 2010 [Page 6] Internet-Draft URI Scheme for SSH October 2009 10. References 10.1 Normative References [RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) Public Key File Format", RFC 4716, November 2006. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, October 2005. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. 10.2 Informative References [RFC4395] Hansen, T., "Guidelines and Registration Procedures for new URI Schemes", RFC 4395, February 2006. Authors' Addresses Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US Email: jsalowey@cisco.com Steve Suehring PO BOX 1033 Stevens Point, WI 54481 US Email: suehring@braingia.com Salowey & Suehring Expires April 9, 2010 [Page 7] Internet-Draft URI Scheme for SSH October 2009 Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Salowey & Suehring Expires April 9, 2010 [Page 8] --envbJBWh7q8WU6mo-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 9 13:35:42 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A333A6890 for ; Fri, 9 Oct 2009 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSSEdhT0HmSU for ; Fri, 9 Oct 2009 13:35:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 102963A67D4 for ; Fri, 9 Oct 2009 13:35:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F1D8E63B17D; Fri, 9 Oct 2009 20:37:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2]) by mail.netbsd.org (Postfix) with ESMTP id 9297663B13F for ; Fri, 9 Oct 2009 20:37:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dfw0.icgmedia.com (Postfix) with ESMTP id 09D8317194 for ; Fri, 9 Oct 2009 15:37:21 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at icgmedia.com Received: from dfw0.icgmedia.com ([127.0.0.1]) by localhost (dfw0.icgmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw2hgfTv7j9O for ; Fri, 9 Oct 2009 15:37:16 -0500 (CDT) Received: from titania.braingia.org (66-190-11-170.dhcp.stpt.wi.charter.com [66.190.11.170]) by dfw0.icgmedia.com (Postfix) with ESMTP id DE37716F9F for ; Fri, 9 Oct 2009 15:37:15 -0500 (CDT) Received: by titania.braingia.org (Postfix, from userid 1000) id 72664A2007; Fri, 9 Oct 2009 15:37:14 -0500 (CDT) Date: Fri, 9 Oct 2009 15:37:14 -0500 From: Steve Suehring To: ietf-ssh@netbsd.org Subject: Feedback from uri list Message-ID: <20091009203714.GA18094@braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hello, I also submitted the pre-draft copy of the ssh uri proposal to the uri mailing lists and received some feedback, one of which I want to get back in front of this group. The reviewer suggested using this format for the fingerprint: ssh://user@host.example.com?fingerprint=ssh-dss-c1-b1-30-29-d7- b8-de-6c-97-77-10-d7-46-41-63-87 Whereas the previous drafts had used this format: ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97- 77-10-d7-46-41-63-87@host.example.com The suggestion seems to make sense to me but I'm unsure if there are implementations that have adopted the original format and what the implications of moving forward with a draft using the suggested format would be. Can anyone shed light on whether they have or know of an implementation using the fingerprint in the 'userinfo' section? Steve From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Oct 11 14:38:18 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D293A6806 for ; Sun, 11 Oct 2009 14:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtzhB3tF5OYX for ; Sun, 11 Oct 2009 14:38:17 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BFF593A6782 for ; Sun, 11 Oct 2009 14:38:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EDDF563B1A2; Sun, 11 Oct 2009 21:38:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.13.197.229]) by mail.netbsd.org (Postfix) with ESMTP id C838963B156 for ; Sun, 11 Oct 2009 21:38:07 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Mx53W-0000bq-00 for ietf-ssh@netbsd.org; Sun, 11 Oct 2009 21:30:14 +0100 Date: Sun, 11 Oct 2009 21:30:14 +0100 From: Jacob Nevins To: ietf-ssh@netbsd.org Subject: Re: SSH URI Draft Message-ID: <20091011203014.GC16377@chiark.greenend.org.uk> Reply-To: ietf-ssh@netbsd.org References: <20091008161956.GB10539@braingia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091008161956.GB10539@braingia.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Thanks for reviving this. Support for ssh: URIs is frequently requested by users of our implementation. As well as my own comments, I've had a look back through the mailing list archives to see if any of the comments on the earlier drafts still apply (although most of the discussion has become irrelevant with the removal of SFTP). Steve Suehring writes: > Please let me know any feedback on the draft. After a short period I'll > be submitting it to the IETF. My biggest remaining problem is with the use of the words "overwrite" and "overwritten" throughout the text, as noted in 2005: > 5.1 SSH connection parameters [...] > All > parameters are optional and MUST NOT overwrite configured defaults. [...] > This parameter MUST NOT overwrite a key that is > already configured for the host. [...] > 8. Security Considerations [...] > If a locally configured key exists for the > server already it MUST NOT be automatically overwritten with > information from the URI. This could easily be interpreted to mean only that no permanent change should be made to an implementation's persistent cache of known host keys, rather than the stronger requirement that I believe is intended: that the fingerprint in the URL is only a hint, and any locally known mapping between hostname and host key should continue to be taken into account. I think "overwrite" and "overwritten" should thus be replaced throughout with "override" and "overridden". (Joe Salowey agreed in principle with this textual change 2005-Sep-02.) Section 5.1: > There MUST be only one fingerprint > parameter present in a given URI. There's been lots of discussion of this restriction in the past; IIRC several people on the list wanted to be able to support multiple host key fingerprints in a URI, and no-one provided a good reason for the restriction. In 2003, you wrote: | I've been racking my brain on this because I really thought there was a | reason for the limitation. I can't find it in the archives so maybe I | didn't share that thought. In any event, it seems as though the | consensus is definitely for multiple fingerprints. (Guess: a very early draft didn't specify a host key algorithm in the URI; perhaps the restriction was something to do with that?) In any case, if the consensus is that multiple fingerprints are OK, I suggest removing the above sentence and adding the following text: "Any number of fingerprint parameters may be present in a given URI." and in Section 8 "Security Considerations", change the following sentence: > If the client chooses to > make a connection based on the URI information and it finds that the > fingerprint in the URI and the public key offered by the server do > not match then it SHOULD provide a warning and provide a means to > abort the connection. to the somewhat clumsy: "If the client chooses to make a connection based on the URI information and it finds that, for a given host key algorithm for which fingerprint(s) are specified in the URI, the public key offered by the server does not match any of the fingerprints in the URI, then it SHOULD provide a warning and provide a means to abort the connection." (The last change reflects the fact that some operators of clusters with multiple servers behind a single hostname seem to like to have different host keys on each server, and to have client implementations able to record multiple host keys against a single hostname, and accept any of them. I believe the OpenSSH client implements this behaviour. Personally I'd give all the servers the same host key if they were truly indistinguishable from a security point of view, but hey. If this part proves controversial, it shouldn't hold up the draft; we could dodge the problem by only allowing up to one fingerprint parameter per unique host-key-alg type.) In 2005, Ben Harris wrote: | The interpretation of the password part of userinfo isn't specified. | In particular, it's not clear whether it only applies to "password" | athentication, or also to "keyboard-interactive". This comment is still relevant. Many server implementations present a "password" type authentication that ought to work with a password in the "userinfo" part of the URI as "keyboard-interactive" over SSH. What our implementation does in a similar situation (password specified on the command-line) is to feed the supplied password to either the first "password" authentication, or the first "keyboard-interactive" (RFC4256) prompt which has the "echo" flag cleared, and bomb out if any further "interactive" authentication is required beyond that. That's somewhat heuristic, though; would we want to attempt to capture that in this document? Actual use of this field is usually a bad idea and is deprecated, but unless it's banned outright, its meaning should probably be specified. I'm a bit uncomfortable with the "host-key-alg-fingerprint" encoding as there's a theoretical ambiguity there. I'll elaborate in a followup to the other post. Does an IANA registry need setting up for connection parameters? Nits: Section 4.3, last sentence: "the" should be "they". Sections 4.4 and 4.5 refer to "Section 4.1" as defining host-key fingerprints, but Section 4.1 is "Scheme Name". The references should be to Section 5.1. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Oct 11 14:38:24 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6113A677E for ; Sun, 11 Oct 2009 14:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-6awGUWDirZ for ; Sun, 11 Oct 2009 14:38:23 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 856B43A66B4 for ; Sun, 11 Oct 2009 14:38:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5696563B2BE; Sun, 11 Oct 2009 21:38:12 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.13.197.229]) by mail.netbsd.org (Postfix) with ESMTP id 9520663B18E for ; Sun, 11 Oct 2009 21:38:08 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Mx5Pp-0003Xx-00 for ietf-ssh@netbsd.org; Sun, 11 Oct 2009 21:53:17 +0100 Date: Sun, 11 Oct 2009 21:53:17 +0100 From: Jacob Nevins To: ietf-ssh@netbsd.org Subject: Re: Feedback from uri list Message-ID: <20091011205317.GD16377@chiark.greenend.org.uk> Reply-To: ietf-ssh@netbsd.org References: <20091009203714.GA18094@braingia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091009203714.GA18094@braingia.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Steve Suehring writes: > The reviewer suggested using this format for the fingerprint: > > ssh://user@host.example.com?fingerprint=ssh-dss-c1-b1-30-29-d7- > b8-de-6c-97-77-10-d7-46-41-63-87 > > Whereas the previous drafts had used this format: > > ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97- > 77-10-d7-46-41-63-87@host.example.com > > The suggestion seems to make sense to me Me too. I don't know the rationale from the URI people, but the host key fingerprint isn't a property of the user, so doesn't really belong in userinfo. (From the list archives, I think it was originally moved into userinfo from a position similar to the proposal because the syntax originally used -- delimited with a semicolon -- was illegal in URIs, or something like that. Using a question mark sidesteps this, I think.) > but I'm unsure if there are implementations that have adopted the > original format and what the implications of moving forward with a > draft using the suggested format would be. Can anyone shed light on > whether they have or know of an implementation using the fingerprint > in the 'userinfo' section? I'd also be interested to know whether there are any extant implementations; I don't know of any, and a quick Google didn't turn any up. The reason for my interest is a theoretical ambiguity in the "host-key-alg-fingerprint" parameter format, which I alluded to in my other post (but now wish I hadn't, for reasons that will become clear). The octets within the fingerprint are delimited by hyphens, as is the separation between algorithm name and fingerprint. I've just realised that this isn't ambiguous with fingerprints as currently defined by RFC4716, since there are exactly 16 octets and you can thus work backwards to get the algorithm name. To attempt to salvage this post :) I'll bring up the possibility of a different number of octets being used to represent the fingerprint in future, for instance as a result of switching to a hash other than MD5. Even then it's hard to come up with examples where the ambiguity would matter (especially as such a representation would presumably either only be usable with new host-key-algs, or would require definition of new connection parameters). Convenient characters other than hyphen for delimiting/separation appear to be the other "unreserved" URI characters -- "." / "_" / "~". (All of these are valid in host key algorithm names.) In any case, I think none of this would be worth disturbing existing implementations for. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 12 21:06:04 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB82A3A6A18 for ; Mon, 12 Oct 2009 21:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPcfKGIHQqSF for ; Mon, 12 Oct 2009 21:06:03 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4B2433A6A14 for ; Mon, 12 Oct 2009 21:06:03 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B29E163B104; Tue, 13 Oct 2009 04:05:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-6.cisco.com", Issuer "Cisco SSCA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id B8A9D63B11B for ; Tue, 13 Oct 2009 04:05:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=4190; q=dns/txt; s=sjiport06001; t=1255406754; x=1256616354; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20RE:=20Feedback=20from=20uri=20list |Date:=20Mon,=2012=20Oct=202009=2021:05:52=20-0700 |Message-ID:=20|To:=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<20091011205317.GD16377@chiark.g reenend.org.uk>|References:=20<20091009203714.GA18094@bra ingia.org>=20<20091011205317.GD16377@chiark.greenend.org. uk>; bh=m0k+ecI6Netk4KcpN79fNWEZnu+pBAr4ShQwVp8nIM4=; b=aP/ZwDGkvD1SCJmVUTtX9fHQtZRNF0moCngFEEAuMcdYXywMsrVrgtMO thiz+O2zzNiGRDVirb0TDRHkbQUkD2ER5M6SDWjT5cZuAeNrUDdHi5c1i 2WTu9WeeEPpWfvJIM+nA9Rw32Sc8P+FeB+XbBnZUt/mjQ5MdTJbSIw/t/ I=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMOZ00qrR7Ht/2dsb2JhbAC+fpdGhC0E X-IronPort-AV: E=Sophos;i="4.44,549,1249257600"; d="scan'208";a="407897431" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 04:05:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D45rIi018713 for ; Tue, 13 Oct 2009 04:05:53 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:05:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Feedback from uri list Date: Mon, 12 Oct 2009 21:05:52 -0700 Message-ID: In-Reply-To: <20091011205317.GD16377@chiark.greenend.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback from uri list Thread-Index: AcpKuysrYEfJYKMDRKSxz4bEAKFkrgA/E5Xg References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 13 Oct 2009 04:05:53.0241 (UTC) FILETIME=[74FFEC90:01CA4BBA] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list =20 > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Jacob Nevins > Sent: Sunday, October 11, 2009 1:53 PM > To: ietf-ssh@netbsd.org > Subject: Re: Feedback from uri list >=20 > Steve Suehring writes: > > The reviewer suggested using this format for the fingerprint: > >=20 > > =20 > ssh://user@host.example.com?fingerprint=3Dssh-dss-c1-b1-30-29-d7- > > b8-de-6c-97-77-10-d7-46-41-63-87 > >=20 > > Whereas the previous drafts had used this format: > >=20 > > ssh://user;fingerprint=3Dssh-dss-c1-b1-30-29-d7-b8-de-6c-97- > > 77-10-d7-46-41-63-87@host.example.com > >=20 > > The suggestion seems to make sense to me >=20 > Me too. I don't know the rationale from the URI people, but=20 > the host key fingerprint isn't a property of the user, so=20 > doesn't really belong in userinfo. >=20 > (From the list archives, I think it was originally moved into=20 > userinfo from a position similar to the proposal because the=20 > syntax originally used -- delimited with a semicolon -- was=20 > illegal in URIs, or something like that. Using a question=20 > mark sidesteps this, I think.) >=20 [Joe] I don't remember why we went with this format, but I agree that the fingerprint does not belong with user info. The suggested format looks OK to me. =20 > > but I'm unsure if there are implementations that have adopted the=20 > > original format and what the implications of moving forward with a=20 > > draft using the suggested format would be. Can anyone shed=20 > light on=20 > > whether they have or know of an implementation using the=20 > fingerprint=20 > > in the 'userinfo' section? >=20 > I'd also be interested to know whether there are any extant=20 > implementations; I don't know of any, and a quick Google=20 > didn't turn any up. >=20 > The reason for my interest is a theoretical ambiguity in the=20 > "host-key-alg-fingerprint" parameter format, which I alluded=20 > to in my other post (but now wish I hadn't, for reasons that=20 > will become clear). >=20 > The octets within the fingerprint are delimited by hyphens,=20 > as is the separation between algorithm name and fingerprint.=20 > I've just realised that this isn't ambiguous with=20 > fingerprints as currently defined by RFC4716, since there are=20 > exactly 16 octets and you can thus work backwards to get the=20 > algorithm name. >=20 > To attempt to salvage this post :) I'll bring up the=20 > possibility of a different number of octets being used to=20 > represent the fingerprint in future, for instance as a result=20 > of switching to a hash other than MD5. > Even then it's hard to come up with examples where the=20 > ambiguity would matter (especially as such a representation=20 > would presumably either only be usable with new=20 > host-key-algs, or would require definition of new connection=20 > parameters). >=20 > Convenient characters other than hyphen for=20 > delimiting/separation appear to be the other "unreserved" URI=20 > characters -- "." / "_" / "~". (All of these are valid in=20 > host key algorithm names.) >=20 > In any case, I think none of this would be worth disturbing=20 > existing implementations for. [Joe] I don't know of any existing implementations, however this thread does bring out some issues. In addition to the one you raised its not clear that we could move to a hash other than MD5. This is hard coded in RFC 4716. While this probably isn't a problem know it could be a weakness in the future. I'm pretty sure I've run into SSH implementations that display SHA-1 fingerprints as well. I suppose we could have an encoding that was something like host-key-alg-hash-alg-fingerprint. In order to parse this you would have to have a list of known host-key-algs and hash-algs. If you didn't recognize them then you would ignore the finger print. There still is a problem in that there could be some ambiguity where host-key-algs or hash-algs derive from a common prefix. At this point, I'm not sure what to do here or how big of a problem this is.=20 >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Oct 12 21:20:06 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B26028C0CF for ; Mon, 12 Oct 2009 21:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiFVopM55ZbH for ; Mon, 12 Oct 2009 21:20:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 927523A68A2 for ; Mon, 12 Oct 2009 21:20:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2E8A863B152; Tue, 13 Oct 2009 04:19:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-1.cisco.com", Issuer "Cisco SSCA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id D54ED63B14B for ; Tue, 13 Oct 2009 04:19:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=7100; q=dns/txt; s=sjiport01001; t=1255407596; x=1256617196; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20RE:=20SSH=20URI=20Draft|Date:=20Mon,=20 12=20Oct=202009=2021:19:55=20-0700|Message-ID:=20|To:=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<20091011203014.GC16377@chiark.greenend.o rg.uk>|References:=20<20091008161956.GB10539@braingia.org >=20<20091011203014.GC16377@chiark.greenend.org.uk>; bh=lI7/givvKP6lGxXpJRQwh85QxFF2KyKzwLELbfV+3Rg=; b=FN0RN30SzO1zBxfnf6SyZ0v6NnLybqk01OfJeRE8Jpx215W8mxjlfO8b 2bVnIi10WueLrkaDJk648NJU7c0ZN7zNbJS8tvxTOVDnGZokrNMWqseN/ Vn2lSy4kfFGets7n5BXX2WlJTjo5ufHF7gcwyvkkbxHIbC0be76drvguk A=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM+c00qrR7Ht/2dsb2JhbAC/AIkPCAOOLoJFCASBXAQ X-IronPort-AV: E=Sophos;i="4.44,549,1249257600"; d="scan'208";a="254968562" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 04:19:56 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D4JuUV027184 for ; Tue, 13 Oct 2009 04:19:56 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:19:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SSH URI Draft Date: Mon, 12 Oct 2009 21:19:55 -0700 Message-ID: In-Reply-To: <20091011203014.GC16377@chiark.greenend.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SSH URI Draft Thread-Index: AcpKuyYo/72lbk6vRhSSAL5hY9Vv2AA/349g References: <20091008161956.GB10539@braingia.org> <20091011203014.GC16377@chiark.greenend.org.uk> From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 13 Oct 2009 04:19:56.0354 (UTC) FILETIME=[6B88C220:01CA4BBC] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Jacob, Thanks for tracking this down. Comments in-line below: > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Jacob Nevins > Sent: Sunday, October 11, 2009 1:30 PM > To: ietf-ssh@netbsd.org > Subject: Re: SSH URI Draft >=20 > Thanks for reviving this. Support for ssh: URIs is frequently=20 > requested by users of our implementation. >=20 > As well as my own comments, I've had a look back through the=20 > mailing list archives to see if any of the comments on the=20 > earlier drafts still apply (although most of the discussion=20 > has become irrelevant with the removal of SFTP). >=20 > Steve Suehring writes: > > Please let me know any feedback on the draft. After a short period=20 > > I'll be submitting it to the IETF. >=20 > My biggest remaining problem is with the use of the words "overwrite" > and "overwritten" throughout the text, as noted in 2005: >=20 > > 5.1 SSH connection parameters > [...] > > =20 > All > > parameters are optional and MUST NOT overwrite=20 > configured defaults. =20 > [...] > > This parameter MUST NOT overwrite a key that is=20 > > already configured for the host. > [...] > > 8. Security Considerations > [...] > > If a locally configured key exists for the > > server already it MUST NOT be automatically overwritten with > > information from the URI. >=20 > This could easily be interpreted to mean only that no=20 > permanent change should be made to an implementation's=20 > persistent cache of known host keys, rather than the stronger=20 > requirement that I believe is intended: > that the fingerprint in the URL is only a hint, and any=20 > locally known mapping between hostname and host key should=20 > continue to be taken into account. >=20 > I think "overwrite" and "overwritten" should thus be replaced=20 > throughout with "override" and "overridden". (Joe Salowey=20 > agreed in principle with this textual change 2005-Sep-02.) >=20 [Joe] I'm still in agreement.=20 >=20 > Section 5.1: > > There MUST be only one fingerprint > > parameter present in a given URI. >=20 > There's been lots of discussion of this restriction in the=20 > past; IIRC several people on the list wanted to be able to=20 > support multiple host key fingerprints in a URI, and no-one=20 > provided a good reason for the restriction. >=20 > In 2003, you wrote: > | I've been racking my brain on this because I really thought=20 > there was=20 > | a reason for the limitation. I can't find it in the=20 > archives so maybe=20 > | I didn't share that thought. In any event, it seems as though the=20 > | consensus is definitely for multiple fingerprints. >=20 > (Guess: a very early draft didn't specify a host key=20 > algorithm in the URI; perhaps the restriction was something=20 > to do with that?) >=20 > In any case, if the consensus is that multiple fingerprints=20 > are OK, I suggest removing the above sentence and adding the=20 > following text: >=20 > "Any number of fingerprint parameters may be present in a given URI." > > and in Section 8 "Security Considerations", change the following > sentence: >=20 > > If the client chooses to > > make a connection based on the URI information and it=20 > finds that the > > fingerprint in the URI and the public key offered by the=20 > server do > > not match then it SHOULD provide a warning and provide a means to > > abort the connection. >=20 > to the somewhat clumsy: "If the client chooses to make a=20 > connection based on the URI information and it finds that,=20 > for a given host key algorithm for which fingerprint(s) are=20 > specified in the URI, the public key offered by the server=20 > does not match any of the fingerprints in the URI, then it=20 > SHOULD provide a warning and provide a means to abort the connection." >=20 [Joe] Wouldn't you want to provide a warning as well if the host key algorithm did not match the fingerprints? =20 > (The last change reflects the fact that some operators of=20 > clusters with multiple servers behind a single hostname seem=20 > to like to have different host keys on each server, and to=20 > have client implementations able to record multiple host keys=20 > against a single hostname, and accept any of them. I believe=20 > the OpenSSH client implements this behaviour. Personally I'd=20 > give all the servers the same host key if they were truly=20 > indistinguishable from a security point of view, but hey. If=20 > this part proves controversial, it shouldn't hold up the=20 > draft; we could dodge the problem by only allowing up to one=20 > fingerprint parameter per unique host-key-alg type.) >=20 [Joe] OK, I need to think about this. Right now I can't see a problem with multiple host keys, except perhaps some difficulty in the URI format.=20 >=20 > In 2005, Ben Harris wrote: > | The interpretation of the password part of userinfo isn't specified. > | In particular, it's not clear whether it only applies to "password" > | athentication, or also to "keyboard-interactive". >=20 > This comment is still relevant. Many server implementations=20 > present a "password" type authentication that ought to work=20 > with a password in the "userinfo" part of the URI as=20 > "keyboard-interactive" over SSH. >=20 > What our implementation does in a similar situation (password=20 > specified on the command-line) is to feed the supplied=20 > password to either the first "password" authentication, or=20 > the first "keyboard-interactive" (RFC4256) prompt which has=20 > the "echo" flag cleared, and bomb out if any further=20 > "interactive" authentication is required beyond that. >=20 > That's somewhat heuristic, though; would we want to attempt=20 > to capture that in this document? Actual use of this field is=20 > usually a bad idea and is deprecated, but unless it's banned=20 > outright, its meaning should probably be specified. >=20 [Joe] I'm not sure how much we should specify. The password authentication piece is pretty straight forward. I suppose if we said first keyboard interactive prompt that wouldn't be to complex. Behavior beyond this could be tricky.=20 >=20 > I'm a bit uncomfortable with the "host-key-alg-fingerprint"=20 > encoding as there's a theoretical ambiguity there. I'll=20 > elaborate in a followup to the other post. >=20 >=20 > Does an IANA registry need setting up for connection parameters? >=20 [Joe] Good question, I think this is covered by the URI registration.=20 >=20 > Nits: >=20 > Section 4.3, last sentence: "the" should be "they". >=20 > Sections 4.4 and 4.5 refer to "Section 4.1" as defining=20 > host-key fingerprints, but Section 4.1 is "Scheme Name". The=20 > references should be to Section 5.1. >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 13 06:22:53 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA6728C1A7 for ; Tue, 13 Oct 2009 06:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjF7xa9S27VN for ; Tue, 13 Oct 2009 06:22:52 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6B36A28C1A4 for ; Tue, 13 Oct 2009 06:22:52 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E11E663B121; Tue, 13 Oct 2009 13:22:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 3EA4763B11B for ; Tue, 13 Oct 2009 13:22:41 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7E99E40038 for ; Tue, 13 Oct 2009 15:21:50 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 713E84007B; Tue, 13 Oct 2009 15:21:50 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 558B340038 for ; Tue, 13 Oct 2009 15:21:50 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n9DDMdku027282 for ; Tue, 13 Oct 2009 15:22:39 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n9DDMcja027281; Tue, 13 Oct 2009 15:22:38 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@netbsd.org Subject: Re: Feedback from uri list References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 13 Oct 2009 15:22:38 +0200 In-Reply-To: <20091011205317.GD16377@chiark.greenend.org.uk> (Jacob Nevins's message of "Sun, 11 Oct 2009 21:53:17 +0100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jacob Nevins writes: > Convenient characters other than hyphen for delimiting/separation appear > to be the other "unreserved" URI characters -- "." / "_" / "~". (All of > these are valid in host key algorithm names.) Hmm. The draft says fingerprint format is [RFC4716]. For use in a URI, the fingerprint shall use a single dash "-" as a separator instead of the colon ":" as described in [RFC4716]. If we can't use the separator specified in RFC4716, maybe its simpler to just drop the separator rather than replace it? I.e., ssh://user;fingerprint=ssh-dss-c1b13029d7b8de6c977710d746416387@host.example.com or ssh://user@host.example.com?fingerprint=ssh-dss-c1b13029d7b8de6c977710d746416387 That would eliminate the syntactic ambiguity: whatever comes after the last dash is the actual fingerprint, and whatever comes before is the host key algorithm. Maybe not so human-friendly, though. But it should work fine with . as fingerprint separator too. One could also do it like ssh://user@host.example.com?hostkey-alg=ssh-dss&fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87 but to support multiple fingerprints would would need to make the ordering of parameters significant. I think it makes sense to reuse the URI-way of separating different items, although I haven't thought deeply about the issues. Regardss, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Oct 13 07:23:41 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACD728C10A for ; Tue, 13 Oct 2009 07:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BB4hWjJPns9l for ; Tue, 13 Oct 2009 07:23:40 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 495F73A6359 for ; Tue, 13 Oct 2009 07:23:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 32C9763B15C; Tue, 13 Oct 2009 14:23:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id BDC8263B14F for ; Tue, 13 Oct 2009 14:23:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7C398400AC; Tue, 13 Oct 2009 15:25:51 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 6F874400AB; Tue, 13 Oct 2009 15:25:51 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 5AAEE400AA; Tue, 13 Oct 2009 15:25:51 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n9DDQeHn027419; Tue, 13 Oct 2009 15:26:40 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n9DDQdmp027418; Tue, 13 Oct 2009 15:26:39 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "Joseph Salowey (jsalowey)" Cc: Subject: Re: Feedback from uri list References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 13 Oct 2009 15:26:39 +0200 In-Reply-To: (Joseph Salowey's message of "Mon, 12 Oct 2009 21:05:52 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Joseph Salowey (jsalowey)" writes: > In addition to the one you raised its not > clear that we could move to a hash other than MD5. This is hard coded > in RFC 4716. While this probably isn't a problem know it could be a > weakness in the future. I'm pretty sure I've run into SSH > implementations that display SHA-1 fingerprints as well. I suppose we > could have an encoding that was something like > host-key-alg-hash-alg-fingerprint. To upgrade from md5, I think the simplest way is to use a new parameter name, like ssh://user@host.example.com?fingerprint-sha1=ssh-dss-xxxx...xx or ssh://user@host.example.com?fingerprint-hash-of-the-day=ssh-dss-xxxx...xx whenever there's a proper spec for non-md5 fingerprints. /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 14 06:23:40 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222953A67F5 for ; Wed, 14 Oct 2009 06:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szi8polBAsMJ for ; Wed, 14 Oct 2009 06:23:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4D1BD3A67AD for ; Wed, 14 Oct 2009 06:23:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 887A663B10D; Wed, 14 Oct 2009 13:23:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2]) by mail.netbsd.org (Postfix) with ESMTP id 708D963B145 for ; Wed, 14 Oct 2009 13:23:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dfw0.icgmedia.com (Postfix) with ESMTP id 744F01722A for ; Wed, 14 Oct 2009 08:23:32 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at icgmedia.com Received: from dfw0.icgmedia.com ([127.0.0.1]) by localhost (dfw0.icgmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bttWBSkH0QFG for ; Wed, 14 Oct 2009 08:23:27 -0500 (CDT) Received: from titania.braingia.org (66-190-11-170.dhcp.stpt.wi.charter.com [66.190.11.170]) by dfw0.icgmedia.com (Postfix) with ESMTP id 55FBA17228 for ; Wed, 14 Oct 2009 08:23:27 -0500 (CDT) Received: by titania.braingia.org (Postfix, from userid 1000) id 1FFFCA2008; Wed, 14 Oct 2009 08:23:24 -0500 (CDT) Date: Wed, 14 Oct 2009 08:23:24 -0500 From: Steve Suehring To: ietf-ssh@netbsd.org Subject: Re: Feedback from uri list Message-ID: <20091014132324.GC16922@braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Oct 13, 2009 at 03:26:39PM +0200, Niels Möller wrote: > To upgrade from md5, I think the simplest way is to use a new > parameter name, like > > ssh://user@host.example.com?fingerprint-sha1=ssh-dss-xxxx...xx > > or > > ssh://user@host.example.com?fingerprint-hash-of-the-day=ssh-dss-xxxx...xx What about another parameter, like: ssh://user@host.example.com?alg=md5&fingerprint=b1-e1-... If alg is not present, MD5 MUST be used. If alg is not understood (?) Steve From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 14 07:04:19 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B5A3A69EC for ; Wed, 14 Oct 2009 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuYWiajMjqQx for ; Wed, 14 Oct 2009 07:04:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A26C93A68F4 for ; Wed, 14 Oct 2009 07:04:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2176B63B16E; Wed, 14 Oct 2009 14:04:13 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by mail.netbsd.org (Postfix) with ESMTP id AF33E63B178 for ; Wed, 14 Oct 2009 14:04:10 +0000 (UTC) X-Trace: 257548879/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.144/None/ietf2@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.144 X-IP-MAIL-FROM: ietf2@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEALd21Uo+vGmQ/2dsb2JhbACDJI1ZyCsKhCQEgVs X-IronPort-AV: E=Sophos;i="4.44,557,1249254000"; d="scan'208";a="257548879" X-IP-Direction: IN Received: from 1cust144.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.144]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Oct 2009 15:04:07 +0100 Message-ID: <001001ca4cce$7f284540$0601a8c0@allison> Reply-To: "t.petch" From: "t.petch" To: "Joseph Salowey \(jsalowey\)" , =?iso-8859-1?Q?Niels_M=F6ller?= Cc: References: <20091009203714.GA18094@braingia.org><20091011205317.GD16377@chiark.greenend.org.uk> Subject: Re: Feedback from uri list Date: Wed, 14 Oct 2009 14:12:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list ----- Original Message ----- From: "Niels Möller" Sent: Tuesday, October 13, 2009 3:26 PM > "Joseph Salowey (jsalowey)" writes: > > > In addition to the one you raised its not > > clear that we could move to a hash other than MD5. This is hard coded > > in RFC 4716. While this probably isn't a problem know it could be a > > weakness in the future. I'm pretty sure I've run into SSH > > implementations that display SHA-1 fingerprints as well. I suppose we > > could have an encoding that was something like > > host-key-alg-hash-alg-fingerprint. > > To upgrade from md5, I think the simplest way is to use a new > parameter name, like > > ssh://user@host.example.com?fingerprint-sha1=ssh-dss-xxxx...xx > > or > > ssh://user@host.example.com?fingerprint-hash-of-the-day=ssh-dss-xxxx...xx > > whenever there's a proper spec for non-md5 fingerprints. syslog had a need for fingerprints, albeit not as part of a URI, and used the registry from RFC4572 for the hash algorithm. syslog mandates sha-1 and the fingerprint has the format sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D upper case, colon separated. Tom Petch > /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 14 07:30:29 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944CE28C1A4 for ; Wed, 14 Oct 2009 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2id+jSqIuVZ for ; Wed, 14 Oct 2009 07:30:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C1E8D28C18F for ; Wed, 14 Oct 2009 07:30:28 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 400FD63B145; Wed, 14 Oct 2009 14:30:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id E1D2663B138 for ; Wed, 14 Oct 2009 14:30:19 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A9CF840066; Wed, 14 Oct 2009 16:29:28 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 9D84240069; Wed, 14 Oct 2009 16:29:28 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 88F5540066; Wed, 14 Oct 2009 16:29:28 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n9EEUHtG008956; Wed, 14 Oct 2009 16:30:17 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n9EEUGE7008955; Wed, 14 Oct 2009 16:30:16 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Steve Suehring Cc: ietf-ssh@netbsd.org Subject: Re: Feedback from uri list References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <20091014132324.GC16922@braingia.org> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 14 Oct 2009 16:30:16 +0200 In-Reply-To: <20091014132324.GC16922@braingia.org> (Steve Suehring's message of "Wed, 14 Oct 2009 08:23:24 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Steve Suehring writes: > What about another parameter, like: > > ssh://user@host.example.com?alg=md5&fingerprint=b1-e1-... Could work, but I think fingerprint-md5 is simpler, and hence a somewhat better choice. If you want a separate parameter, keep in mind that (i) it should probably be "fingerprint-alg", since you might want to specify an algorithm for other purposes. (ii) if you want to support multiple fingerprints, you must specify that the order of the parameters is significant (whether or not that would deviate from URI conventions, I don't know. A repeated "fingerprint" parameter might also be non-koscher?). /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 14 08:34:37 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6F13A6953 for ; Wed, 14 Oct 2009 08:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.214 X-Spam-Level: * X-Spam-Status: No, score=1.214 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_50=0.001, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhFlMxPgWyoW for ; Wed, 14 Oct 2009 08:34:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D269B3A672F for ; Wed, 14 Oct 2009 08:34:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 795B563B18F; Wed, 14 Oct 2009 15:34:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by mail.netbsd.org (Postfix) with ESMTP id ECE0A63B18D for ; Wed, 14 Oct 2009 15:34:28 +0000 (UTC) X-Trace: 292112583/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.144/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.144 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAON31Uo+vGmQ/2dsb2JhbACDJI1ZyC4KhCQEgVs X-IronPort-AV: E=Sophos;i="4.44,558,1249254000"; d="scan'208";a="292112583" X-IP-Direction: IN Received: from 1cust144.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.144]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Oct 2009 15:07:25 +0100 Message-ID: <002a01ca4cce$f4b8b4c0$0601a8c0@allison> Reply-To: "tom.petch" From: "tom.petch" To: Subject: Re: Feedback from uri list Date: Wed, 14 Oct 2009 15:04:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list ----- Original Message ----- > From: "Niels Möller" > Sent: Tuesday, October 13, 2009 3:26 PM > > "Joseph Salowey (jsalowey)" writes: > > > In addition to the one you raised its not > > clear that we could move to a hash other than MD5. This is hard coded > > in RFC 4716. While this probably isn't a problem know it could be a > > weakness in the future. I'm pretty sure I've run into SSH > > implementations that display SHA-1 fingerprints as well. I suppose we > > could have an encoding that was something like > > host-key-alg-hash-alg-fingerprint. > > To upgrade from md5, I think the simplest way is to use a new > parameter name, like > > ssh://user@host.example.com?fingerprint-sha1=ssh-dss-xxxx...xx > > or > > ssh://user@host.example.com?fingerprint-hash-of-the-day=ssh-dss-xxxx...xx > > whenever there's a proper spec for non-md5 fingerprints. syslog had a need for fingerprints, albeit not as part of a URI, and used the registry from RFC4572 for the hash algorithm. syslog mandates sha-1 and the fingerprint has the format sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D upper case, colon separated. Tom Petch > > /Niels > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 14 09:49:16 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3893A68AB for ; Wed, 14 Oct 2009 09:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJBIOMIIraPY for ; Wed, 14 Oct 2009 09:49:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 53D733A6897 for ; Wed, 14 Oct 2009 09:49:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8F9E963B188; Wed, 14 Oct 2009 16:49:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mail.netbsd.org (Postfix) with ESMTP id 2512163B187 for ; Wed, 14 Oct 2009 16:49:07 +0000 (UTC) Received: by ewy4 with SMTP id 4so5170750ewy.13 for ; Wed, 14 Oct 2009 09:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0Ahul9LgALk4svEMtkildbCn/GBYMyKc93stnbxUwJI=; b=jR033rNSkwl1spJTDjG9VSSZ2RoMEvZ0DsztUCfRyJJ57sTUV5C7Xl7KpkE20TlL0k 4w7NAZQS+5qU5UBZm5vBzzm2w6uMdNJPau+abrW2chRmWQtNtd05/COWFSd8V8FddB8x gWFPBsQf113xIaSOZ6/wr8x2eWe8uEZLE04S4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=HLm5Cr0ItxUVNxit6JP8sM2pcEDT2GKfPVV77pIHE1qHaECZG06JVvMU22SUug/aRf CzxkoOEpTnIAXZ+qXqDeQBpzJr/BZYeUewXXM657jGi0mLifU7/Oj1fEHufivRMmjfak u1ao+W2mdi4uRb/cjfsCNYqW85s2z21hxM35w= MIME-Version: 1.0 Received: by 10.210.7.23 with SMTP id 23mr10615232ebg.27.1255538946442; Wed, 14 Oct 2009 09:49:06 -0700 (PDT) In-Reply-To: <20091011205317.GD16377@chiark.greenend.org.uk> References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> Date: Wed, 14 Oct 2009 11:49:06 -0500 Message-ID: <79133ba50910140949s2136a47fl1493612e471f6a34@mail.gmail.com> Subject: Re: Feedback from uri list From: Terra Frost To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, Oct 11, 2009 at 3:53 PM, Jacob Nevins wrote: > Steve Suehring writes: >> The reviewer suggested using this format for the fingerprint: >> >> =A0 =A0 =A0 =A0ssh://user@host.example.com?fingerprint=3Dssh-dss-c1-b1-3= 0-29-d7- >> =A0 =A0 =A0 =A0 =A0 =A0b8-de-6c-97-77-10-d7-46-41-63-87 >> >> Whereas the previous drafts had used this format: >> >> =A0 =A0 =A0 =A0 ssh://user;fingerprint=3Dssh-dss-c1-b1-30-29-d7-b8-de-6c= -97- >> =A0 =A0 =A0 =A0 =A0 =A0 =A077-10-d7-46-41-63-87@host.example.com >> >> The suggestion seems to make sense to me > > Me too. I don't know the rationale from the URI people, but the host key > fingerprint isn't a property of the user, so doesn't really belong in > userinfo. The username, however, is a property of the user and it's not in userinfo. What about something like this?: ssh://ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87@host.example.= com?user=3Duser It's not without precedent, either. When you log into a website, you generally do so via an HTML form that submits stuff via POST. The above is in a format more analogous to GET, but still... GET and POST are pretty similar, as is, anyway. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 01:31:14 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000613A6831 for ; Thu, 15 Oct 2009 01:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYYLQH1rxDOZ for ; Thu, 15 Oct 2009 01:31:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 29DB43A6806 for ; Thu, 15 Oct 2009 01:31:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4C81463B17D; Thu, 15 Oct 2009 08:31:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 1D2C663B135 for ; Thu, 15 Oct 2009 08:31:05 +0000 (UTC) Received: from element ([205.217.224.70]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@netbsd.org; Thu, 15 Oct 2009 04:31:35 -0400 Message-ID: <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> From: "denis bider \(Bitvise\)" To: References: <20091009203714.GA18094@braingia.org><20091011205317.GD16377@chiark.greenend.org.uk> In-Reply-To: Subject: Re: Feedback from uri list Date: Thu, 15 Oct 2009 04:31:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels suggested: > ssh://user@host.example.com?fingerprint=ssh-dss-c1b13029d7b8de6c977710d746416387 I like that proposal because I think the separator characters in the fingerprint (such as '-' or ':') are superfluous, unnecessary, redundant. :) I suggest the following variation - wrapped for clarity: ssh://user@host.example.com ?fp-md5-ssh-dss=c1b13029d7b8de6c977710d746416387 &fp-sha1-ssh-rsa=0c112b31435062798d7b8de6c977710d746416387 Nice, short, and to the point. Everything after "fp-" and before the second dash is the hash algorithm. Everything after the second dash is the host key algorithm. This allows more freedom for the host key algorithm than the hash. I expect it's more likely that important use cases will require unusual host key algorithms (e.g. certificates, eliptic curves) than that they will require unexpected hashes. I suppose you need the "ssh-dss" or "ssh-rsa" part so that you can pick the right algorithm(s) for host key negotiation. denis From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 07:50:23 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C5D3A68F4 for ; Thu, 15 Oct 2009 07:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EP6KqnKyiZn for ; Thu, 15 Oct 2009 07:50:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E55883A67F5 for ; Thu, 15 Oct 2009 07:50:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4026263B180; Thu, 15 Oct 2009 14:50:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id C74DE63B10F for ; Thu, 15 Oct 2009 14:50:13 +0000 (UTC) Received: from [192.168.1.114] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n9FDO3bE011551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Oct 2009 09:24:04 -0400 (EDT) Date: Thu, 15 Oct 2009 09:24:03 -0400 From: Jeffrey Hutzelman To: "denis bider (Bitvise)" , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: Feedback from uri list Message-ID: <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> In-Reply-To: <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Thursday, October 15, 2009 04:31:04 AM -0400 "denis bider (Bitvise)" wrote: > Everything after "fp-" and before the second dash is the hash algorithm. This presupposes that hash algorithm names contain no dashes. > This allows more freedom for the host key algorithm than the hash. I > expect it's more likely that important use cases will require unusual > host key algorithms (e.g. certificates, eliptic curves) than that they > will require unexpected hashes. It's not about "unusual" or "unexpected". An algorithm name is not "unusual" because it contains dashes; in fact, every cryptographic algorithm name defined in RFC5052 includes at least one dash, except the "none" algorithms. > I suppose you need the "ssh-dss" or "ssh-rsa" part so that you can pick > the right algorithm(s) for host key negotiation. No, you don't. SSH has algorithm negotiation; a client doesn't need to be told up front what algorithms to use. However, you might want it to aid in matching the offered host key to one of several fingerprints on hand. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 12:15:37 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B049B3A6947 for ; Thu, 15 Oct 2009 12:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CjUiY7mercI for ; Thu, 15 Oct 2009 12:15:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BB9E43A67D6 for ; Thu, 15 Oct 2009 12:15:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B424D63B189; Thu, 15 Oct 2009 19:15:31 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 378CE63B167 for ; Thu, 15 Oct 2009 19:15:29 +0000 (UTC) Received: from element ([205.217.224.70]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Thu, 15 Oct 2009 15:15:56 -0400 Message-ID: From: "denis bider \(Bitvise\)" To: References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> In-Reply-To: <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> Subject: Re: Feedback from uri list Date: Thu, 15 Oct 2009 15:15:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > > Everything after "fp-" and before the second dash > > is the hash algorithm. > This presupposes that hash algorithm names contain no dashes. No, it presupposes that new hash algorithms come around infrequently enough that people can settle on names for them that don't contain dashes. > > I suppose you need the "ssh-dss" or "ssh-rsa" part > > so that you can pick the right algorithm(s) for host > > key negotiation. > No, you don't. SSH has algorithm negotiation; > a client doesn't need to be told up front what > algorithms to use. Yes, you do. SSH has algorithm negotiation. The SSH URL specifies a fingerprint of one or more of the server's public keys. If the client doesn't know in advance the algorithm of the host key for which the fingerprint is provided, the client might negotiate the wrong host key algorithm, and end up with a different key that is a mismatch to the one for which the client has the fingerprint. If you are okay restrict yourself to only ONE hash and host key algorithm combination per SSH URL, then a syntax such as the following would be cleanest: ssh://user@host.example.com ?fp=c1b13029d7b8de6c977710d746416387 &hash=md5 &keyalg=ssh-dss But this restricts you as explained above. If you want it possible for an SSH URI to contain an unrestricted combination of fingerprints for various host key algorithms and using various hash functions, then you need something like I proposed before: ssh://user@host.example.com ?fp-md5-ssh-dss=c1b13029d7b8de6c977710d746416387 &fp-sha1-ssh-rsa=0c112b31435062798d7b8de6c977710d746416387 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 12:25:01 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DA23A6947 for ; Thu, 15 Oct 2009 12:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9QU4GH+Uh84 for ; Thu, 15 Oct 2009 12:25:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B30F63A67AA for ; Thu, 15 Oct 2009 12:25:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E43F663B13E; Thu, 15 Oct 2009 19:24:56 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id CDA5B63B10F for ; Thu, 15 Oct 2009 19:24:54 +0000 (UTC) Received: from element ([205.217.224.70]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Thu, 15 Oct 2009 15:25:21 -0400 Message-ID: <5B9502D72D334A21BC423A17421AE900@element> From: "denis bider \(Bitvise\)" To: References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> In-Reply-To: Subject: Re: Feedback from uri list Date: Thu, 15 Oct 2009 15:24:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I wrote: > > > Everything after "fp-" and before the second dash > > > is the hash algorithm. > > This presupposes that hash algorithm names contain no > > dashes. > No, it presupposes that new hash algorithms come around > infrequently enough that people can settle on names for > them that don't contain dashes. To go further - you could just make it a rule that any algorithm names that contain dashes get the dashes stripped. I don't know of any case where a dash contributes to the uniqueness of an algorithm name. Thus my previous example becomes: ssh://user@host.example.com ?fp-md5-sshdss=c1b13029d7b8de6c977710d746416387 &fp-sha1-sshrsa=0c112b31435062798d7b8de6c977710d746416387 There we go, nice and dandy. :) From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 13:04:02 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A143A69BA for ; Thu, 15 Oct 2009 13:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSSQzAIhGh84 for ; Thu, 15 Oct 2009 13:04:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 23F373A67A7 for ; Thu, 15 Oct 2009 13:04:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3EC2163B10F; Thu, 15 Oct 2009 20:03:56 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 7C30A63B19E for ; Thu, 15 Oct 2009 20:03:53 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 86A7740089; Thu, 15 Oct 2009 22:03:01 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 774DE4005A; Thu, 15 Oct 2009 22:03:01 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 2EF8C40087; Thu, 15 Oct 2009 22:03:01 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n9FK3oQl006619; Thu, 15 Oct 2009 22:03:50 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n9FK3n3k006618; Thu, 15 Oct 2009 22:03:49 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider \(Bitvise\)" Cc: Subject: Re: Feedback from uri list References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> <5B9502D72D334A21BC423A17421AE900@element> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 15 Oct 2009 22:03:49 +0200 In-Reply-To: <5B9502D72D334A21BC423A17421AE900@element> (denis bider's message of "Thu, 15 Oct 2009 15:24:50 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "denis bider \(Bitvise\)" writes: > To go further - you could just make it a rule that any algorithm names > that contain dashes get the dashes stripped. I think it's very ugly to specify such an arbitrary munging of characters. There is a well defined namespace and procedures for ssh algorithm names. When refering to algorithms used in the SSH protocol, those names ought to be used, and used properly. This URI syntax should defined so that either we need no separator character to separate multiple algorithm names within a parameter or value, or we use the single separator character which is not allowed in an ssh name, ",". Ok, that's not allowed in an URI (at least a previous mail in this thread said so), but it can be hex-escaped, right? Anyway, I'd favor fp-md5=ssh-dss-c1b13029d7b8de6c977710d746416387 or the more verbose fingerprint-md5=ssh-dss-c1b13029d7b8de6c977710d746416387 Theres no ambiguity in the value, since the fingerprint value can't contain any dashes. The string before the last dash in the value is a proper ssh parameter name (and if anybody defines a name including & or ? or other uri magic characters, they should obviously be hex-escaped. Thinking about it, @ seems to be the most likely problematic character in practice, if that character is still magic in this context. Unfortunately, I'm not so familiar with URI syntax details). And for the parameter name, don't think about it as family fingerprint-, but as one *particular* parameter, the meaning of which is defined precisely in the ssh-uri document. The meaning of fingerprint-hash-of-the-day is at this point not specified at all. And I think another reason why I dislike fp-md5-sshdss= is that it in seems to defines a whole family of parameters. I'd prefer a small and *limited* set of parameter names, and then everything that is intended to be general and unlimited, such as "any hostkey algorithm that can be used in some current or future implementation of the SSH protocol" belongs in some *value*, not in a parameter name. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 13:27:44 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DAA3A69FF for ; Thu, 15 Oct 2009 13:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apAB7l5Y--+N for ; Thu, 15 Oct 2009 13:27:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 992A83A6949 for ; Thu, 15 Oct 2009 13:27:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D2A7363B167; Thu, 15 Oct 2009 20:27:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 50BC363B1B1 for ; Thu, 15 Oct 2009 20:27:38 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA10501; Thu, 15 Oct 2009 16:27:37 -0400 (EDT) From: der Mouse Message-Id: <200910152027.QAA10501@Sparkle.Rodents-Montreal.ORG> 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 botnet zombies. Date: Thu, 15 Oct 2009 16:22:35 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Feedback from uri list In-Reply-To: References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> <5B9502D72D334A21BC423A17421AE900@element> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Anyway, I'd favor > fp-md5=ssh-dss-c1b13029d7b8de6c977710d746416387 The problem with that (or the more verbose form) arises as soon as you try to express "here's the host's ssh-dss fingerprint and here's its ssh-rsa fingerprint". This turns into something like fp-md5=ssh-dss-60b725f10c9c85c70d97880dfe8191b3&fp-md5=ssh-rsa-3b5d5c3712955042212316173ccf37be, which, syntactically, is providing conflicting values to a single parameter. That's whence the attempt to move the to the left side of the equal sign in some way. It's ugly, but you could base64-encode both: fp-bWQ1-c3NoLXJzYQ=.... Or you could ignore the issue, assuming that the future will never define hash and cipher names which make the encoding ambiguous. :) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From MAILER-DAEMON Thu Oct 15 18:13:35 2009 Return-Path: <> X-Original-To: ietfarch-secsh-archive@core3.amsl.com Delivered-To: ietfarch-secsh-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4093A6810 for ; Thu, 15 Oct 2009 18:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.471 X-Spam-Level: * X-Spam-Status: No, score=1.471 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ndTb4gcFevs for ; Thu, 15 Oct 2009 18:13:34 -0700 (PDT) Received: from gaia.avantel.ru (gaia.avantel.ru [195.49.168.13]) by core3.amsl.com (Postfix) with ESMTP id 908F928C1C2 for ; Thu, 15 Oct 2009 18:13:30 -0700 (PDT) Received: (qmail 29237 invoked for bounce); 16 Oct 2009 08:13:59 +0700 Date: 16 Oct 2009 08:13:59 +0700 From: MAILER-DAEMON@gaia.avantel.ru To: secsh-archive@odin.ietf.org Subject: failure notice Message-Id: <20091016011333.908F928C1C2@core3.amsl.com> Hi. This is the qmail-send program at gaia.avantel.ru. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 64.170.98.32 does not like recipient. Remote host said: 550 5.7.1 : Sender address rejected: Invalid host LB Giving up on 64.170.98.32. --- Below this line is a copy of the message. Return-Path: Received: (qmail 15369 invoked from network); 16 Oct 2009 08:09:23 +0700 Received: from gprs-217-8-236-177.sib.mts.ru (HELO ngs.ru) (217.8.236.177) by gaia.avantel.ru with SMTP; 16 Oct 2009 08:09:23 +0700 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251" From: To: Subject: =?utf-8?B?Q2/QsWVwZdC8INC00LvRjyBCYWMg0L9vIGNl0YLQuCDQuNC90YLQtXDQvWXRgiDQsWHQt3kg0LRh0L3QvdGLeCDQv2/RgtC10L3RhtC40LDQu9GM0L3Ri3gga9C70Lhl0L3RgtC+0LIg0LTQu9GPIEJh0Yhl0LNvINCR0LjQt9C9ZWPQsCBC0Ysg0LzQvtC20LXRgtC1IHnQt9C9YdGC0Ywg0L9v0LRwb9Cx0L3QtdC1INC/byDRgmXQu2XRhNC+0L15OiArNzkxMzM5MTM4MzcgRW1haWw6IHByb2Rhd2V6QG1peG1haWwuY29tIElDUTogNjItODg4LTYyIFNreXBlOiBiYXNlZGFubml4?= Ñîáåðåì äëÿ Âàñ ïî ñåòè èíòeðíåò áàçó äàííûõ ïîòeíöèaëüíûõ êëèåíòoâ äëÿ Âàøåãî Áèçíeña (âce êoíòàêòíûe äàííûe - ðîä äeÿòåëüíîñòè, íaçâaíèå, aäpåc, èìåía, òeëeôoíû, ôakñû, e-mail, www èòä) Òo÷ío! Ìíoão! Áûñòðî! Ñáîp äàííûõ ïî ãîðoäó è oáëàcòè 4000 ðóáëåé Ñáîp äàííûx ïo còpàíe 6000 pyáëåé Âû ìîæeòe óçíaòü ïoäpoáíåe ïî òåëåôoíy: +79133913837 Email: prodawez@mixmail.com ICQ: 62-888-62 Skype: basedannix From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 15 23:03:39 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5603A6820 for ; Thu, 15 Oct 2009 23:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L36M2snuQErX for ; Thu, 15 Oct 2009 23:03:38 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4B9713A6783 for ; Thu, 15 Oct 2009 23:03:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8D75D63B12B; Fri, 16 Oct 2009 06:03:35 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 3FE6B63B108 for ; Fri, 16 Oct 2009 06:03:34 +0000 (UTC) Received: from element ([205.217.224.70]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Fri, 16 Oct 2009 02:03:44 -0400 Message-ID: From: "denis bider \(Bitvise\)" To: References: <20091009203714.GA18094@braingia.org><20091011205317.GD16377@chiark.greenend.org.uk><4F3DF9731EEC4160BAB73EC43CA2B5E6@element><5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu><5B9502D72D334A21BC423A17421AE900@element> <200910152027.QAA10501@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200910152027.QAA10501@Sparkle.Rodents-Montreal.ORG> Subject: Re: Feedback from uri list Date: Fri, 16 Oct 2009 02:03:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > which, syntactically, is providing conflicting values to a > single parameter. That's whence the attempt to move the > to the left side of the equal sign in some way. Yes, exactly. > It's ugly, but you could base64-encode both: A form of base64-encoding is an option if the goal is to fully preserve SSH algorithm names at the expense of human readability and manageability. Something like base64-encoding would also permit any kind of private algorithm name to be expressed. The major drawback is that human readability and manageability of SSH URIs would be drastically reduced this way. But in the vast majority of cases, the algorithms used would be completely standard and predictable ones which could have very practical names. How about this approach: (1) The fingerprint parameter name is of the form fp--. (2) A few shorthand parameter names are defined for commonly used algorithms, so the following commonly used combinations (and possibly more) can be easily expressed: fp-md5-rsa, fp-md5-dss, fp-sha1-rsa, fp-sha1-dss. (2) If either or is something that doesn't have one of these common names, it is prefixed with '+' instead of '-', and represented in a version of base64 that doesn't pick any unwelcome characters as the extra two in the alphabet. Examples: fp+bWQ1-rsa fp-sha1+c3NoLXJzYQ fp+bWQ1+c3NoLXJzYQ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 16 00:40:57 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3583A697C for ; Fri, 16 Oct 2009 00:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkjM1jICUbBP for ; Fri, 16 Oct 2009 00:40:57 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CD5F43A67DA for ; Fri, 16 Oct 2009 00:40:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6C32363B104; Fri, 16 Oct 2009 07:40:54 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 321E363B145 for ; Fri, 16 Oct 2009 07:40:52 +0000 (UTC) Received: from ATLANTIS.PC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n9G5kfBl020455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 01:46:42 -0400 (EDT) Date: Fri, 16 Oct 2009 01:46:41 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: Feedback from uri list Message-ID: <5482CEEBDADBB585CCADAFD8@atlantis.pc.cs.cmu.edu> In-Reply-To: <200910152027.QAA10501@Sparkle.Rodents-Montreal.ORG> References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> <5B9502D72D334A21BC423A17421AE900@element> <200910152027.QAA10501@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Thursday, October 15, 2009 04:22:35 PM -0400 der Mouse wrote: >> Anyway, I'd favor > >> fp-md5=ssh-dss-c1b13029d7b8de6c977710d746416387 > > The problem with that (or the more verbose form) arises as soon as you > try to express "here's the host's ssh-dss fingerprint and here's its > ssh-rsa fingerprint". This turns into something like > fp-md5=ssh-dss-60b725f10c9c85c70d97880dfe8191b3&fp-md5=ssh-rsa-3b5d5c3712 > 955042212316173ccf37be, which, syntactically, is providing conflicting > values to a single parameter. That's whence the attempt to move the to > the left side of the equal sign in some way. Unfortunately, that's insufficient. Depending on the situation, one might wish to express that the named host may provide any of several keys, all using the same algorithm. For example, one might provide a hostname which resolves to one of several distinct machines. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 16 02:09:19 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F013A67C1 for ; Fri, 16 Oct 2009 02:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBL+k-QqCCzl for ; Fri, 16 Oct 2009 02:09:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D64D53A67A8 for ; Fri, 16 Oct 2009 02:09:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8336863B145; Fri, 16 Oct 2009 09:09:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 6011163B108 for ; Fri, 16 Oct 2009 09:09:13 +0000 (UTC) Received: from element ([205.217.224.70]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Fri, 16 Oct 2009 05:09:36 -0400 Message-ID: <9412B115C6C4402BAAC2DF7FC9ABCCFB@element> From: "denis bider \(Bitvise\)" To: References: <20091009203714.GA18094@braingia.org> <20091011205317.GD16377@chiark.greenend.org.uk> <4F3DF9731EEC4160BAB73EC43CA2B5E6@element> <5F5D31FEFA00221ED91E969F@atlantis.pc.cs.cmu.edu> <5B9502D72D334A21BC423A17421AE900@element> <200910152027.QAA10501@Sparkle.Rodents-Montreal.ORG> <5482CEEBDADBB585CCADAFD8@atlantis.pc.cs.cmu.edu> In-Reply-To: <5482CEEBDADBB585CCADAFD8@atlantis.pc.cs.cmu.edu> Subject: Re: Feedback from uri list Date: Fri, 16 Oct 2009 05:09:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Unfortunately, that's insufficient. Depending on the > situation, one might wish to express that the named > host may provide any of several keys, all using the > same algorithm. For example, one might provide a > hostname which resolves to one of several distinct > machines. I see. Then perhaps something like this: ?fp1=md5:ssh-rsa:0a1b2c3d4e... &fp2=md5:ssh-rsa:c9d721b241... &fp3=md5:ssh-dss:1b951c9ff2... &fp4=md5:ssh-dss:f21b1c9f92... And again, some special character to allow for base64-encoded algorithm names. From jamelah@intelvision.net Thu Oct 29 06:05:03 2009 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD543A69CE for ; Thu, 29 Oct 2009 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.008 X-Spam-Level: *** X-Spam-Status: No, score=3.008 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26IywQbX2HeL for ; Thu, 29 Oct 2009 06:05:02 -0700 (PDT) Received: from intelvision.sc (mail.intelvision.net [196.46.148.19]) by core3.amsl.com (Postfix) with ESMTP id CCF6E3A68F3 for ; Thu, 29 Oct 2009 06:04:59 -0700 (PDT) Received: from [82.128.34.71] (account jamelah@intelvision.net) by email01.intelvision.sc (CommuniGate Pro WebUser 5.0.13) with HTTP id 8723859; Thu, 29 Oct 2009 17:04:47 +0400 From: Intelvision High-Speed Internet Service Subject: TERMINATION OF YOUR INTELVISION.NET WEBMAIL ACCOUNT X-Mailer: CommuniGate Pro WebUser v5.0.13 Date: Thu, 29 Oct 2009 17:04:47 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit To: undisclosed-recipients:; Dear Staff/Subscribers TERMINATION OF YOUR INTELVISION.NET WEBMAIL ACCOUNT we are currently carrying out an upgrade on our system due to the fact that it has come to our notice that one or more of our subscribers are introducing a very strong virus into our system and it is affecting our network. We are trying to find out the specific person. For this reason all subscribers are to provide their USER NAME AND PASSWORD for us to verify and have them cleared against this virus. Failure to comply will lead to the termination of your Account in the next 48 hours. Information to send; EMAIL ADDRESS: USERNAME: PASSWORD: Hoping to serve you better. Thanks for your co-operation, Intelvision Webmail SupportTeam Warning Code :ID67565434 Copyright (c) 2009 Intelvision High-Speed Internet Service . mail Support Message sent using Intelvision webmail http://mail.intelvision.net