From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jun 1 18:16:08 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 3AC1C3A6813 for ; Mon, 1 Jun 2009 18:16:08 -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 Yy4Z-Nylu-Vs for ; Mon, 1 Jun 2009 18:16:07 -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 6698C3A6801 for ; Mon, 1 Jun 2009 18:16:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D9EF863B185; Tue, 2 Jun 2009 01:15:56 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 1AE5263B196 for ; Tue, 2 Jun 2009 01:15:53 +0000 (UTC) Received: from [10.22.14.169] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n51NOYnV021527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jun 2009 19:24:35 -0400 (EDT) Date: Mon, 01 Jun 2009 16:24:34 -0700 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: Fwd: New Version Notification for draft-green-secsh-ecc-07 Message-ID: <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> In-Reply-To: <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> References: <20090427001853.AEBF23A68DB@core3.amsl.com> <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> A new version of I-D, draft-green-secsh-ecc-07.txt has been >> successfuly submitted by Douglas Stebila and posted to the IETF >> repository. >> >> Filename: draft-green-secsh-ecc >> Revision: 07 >> Title: Elliptic-Curve Algorithm Integration in the Secure Shell >> Transport Layer >> Creation_date: 2009-04-27 >> WG ID: Independent Submission >> Number_of_pages: 23 >> >> Abstract: >> This document describes algorithms based on Elliptic Curve >> Cryptography (ECC) for use within the Secure Shell (SSH) transport >> protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman >> (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key >> agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for >> use in the SSH Transport Layer protocol. Has anyone here tried to implement this? I'm in the process of preparing a writeup to go along with the publication request for this document, and I'd like to hear from anyone willing to share their implementation experience. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jun 1 20:30: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 300693A6A6E for ; Mon, 1 Jun 2009 20:30:02 -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 dLlZuL5JD0XK for ; Mon, 1 Jun 2009 20:30: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 27CBF3A68FF for ; Mon, 1 Jun 2009 20:30:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DAD2363B11D; Tue, 2 Jun 2009 03:29:53 +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 05E1963B113 for ; Tue, 2 Jun 2009 03:29:50 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id XAA04430; Mon, 1 Jun 2009 23:29:49 -0400 (EDT) From: der Mouse Message-Id: <200906020329.XAA04430@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: Mon, 1 Jun 2009 23:20:24 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Fwd: New Version Notification for draft-green-secsh-ecc-07 In-Reply-To: <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> References: <20090427001853.AEBF23A68DB@core3.amsl.com> <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>> Filename: draft-green-secsh-ecc > Has anyone here tried to implement this? I'd like to, but it appears unimplementable without copies of X9.63 and IEEE1363, with no indication where to find either. (Past experience with ANSI and IEEE leads me to expect that each is pay-to-play, which, if true, makes this draft a total non-starter in my opinion.) If that guess is wrong, and you can point me at enough documentation to actually build an implementation, I would love to have at it. /~\ 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jun 1 21:42:46 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 546263A6C7D for ; Mon, 1 Jun 2009 21:42:46 -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 A0RTVMNev+VE for ; Mon, 1 Jun 2009 21:42:45 -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 2E9203A6C77 for ; Mon, 1 Jun 2009 21:42:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 584C663B113; Tue, 2 Jun 2009 04:42:38 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id E803463B115 for ; Tue, 2 Jun 2009 04:42:35 +0000 (UTC) Received: from [131.181.103.207] ([131.181.103.207]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n523cg0q021875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jun 2009 23:38:48 -0400 (EDT) Cc: ietf-ssh@NetBSD.org Message-Id: <71FF9C19-7F06-42AD-A8B5-D766A67F23CA@stebila.ca> From: Douglas Stebila To: der Mouse In-Reply-To: <200906020329.XAA04430@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-green-secsh-ecc-07 Date: Tue, 2 Jun 2009 13:38:36 +1000 References: <20090427001853.AEBF23A68DB@core3.amsl.com> <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> <200906020329.XAA04430@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Mon, 01 Jun 2009 23:38:49 -0400 (EDT) X-Miltered: at mailchk-m02 with ID 4A249EC2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: clamav-milter 0.95.1 at mailchk-m05 X-Virus-Status: Clean X-UUID: 19e185ad-149f-464f-b28c-32ae4c96341a Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On 2009-Jun-2, at 1:20 PM, der Mouse wrote: >>>> Filename: draft-green-secsh-ecc >> Has anyone here tried to implement this? > > I'd like to, but it appears unimplementable without copies of X9.63 > and > IEEE1363, with no indication where to find either. (Past experience > with ANSI and IEEE leads me to expect that each is pay-to-play, which, > if true, makes this draft a total non-starter in my opinion.) > > If that guess is wrong, and you can point me at enough documentation > to > actually build an implementation, I would love to have at it. ANSI X9.63 and IEEE 1363 are listed as informative references only. I believe that SEC 1, listed as a normative reference, contains all information required to implement ECDH, ECDSA, and ECMQV; it is freely available from the URL in the references. Is there something specific that you believe requires ANSI X9.63 or IEEE 1363, or some wording that I should clarify? Douglas From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jun 1 21:55:20 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 286973A6CC7 for ; Mon, 1 Jun 2009 21:55:20 -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 gvTCjy2wgDQK for ; Mon, 1 Jun 2009 21:55: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 50EFB3A6955 for ; Mon, 1 Jun 2009 21:53:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 57BAA63B110; Tue, 2 Jun 2009 04:53:51 +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 BBEDB63B11B for ; Tue, 2 Jun 2009 04:53:48 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id AAA09897; Tue, 2 Jun 2009 00:16:43 -0400 (EDT) From: der Mouse Message-Id: <200906020416.AAA09897@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: Tue, 2 Jun 2009 00:04:03 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New Version Notification for draft-green-secsh-ecc-07 In-Reply-To: <71FF9C19-7F06-42AD-A8B5-D766A67F23CA@stebila.ca> References: <20090427001853.AEBF23A68DB@core3.amsl.com> <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> <200906020329.XAA04430@Sparkle.Rodents-Montreal.ORG> <71FF9C19-7F06-42AD-A8B5-D766A67F23CA@stebila.ca> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> Has anyone here tried to implement [draft-green-secsh-ecc]? >> I'd like to, but it appears unimplementable without copies of X9.63 >> and IEEE1363, [...] > ANSI X9.63 and IEEE 1363 are listed as informative references only. > I believe that SEC 1, listed as a normative reference, contains all > information required to implement ECDH, ECDSA, and ECMQV; it is > freely available from the URL in the references. Actually, it is not; it is at least two and I think three links removed from the URL in the references. (The shortest path I've found is http://www.secg.org/ -> "Documents" -> http://www.secg.org/index.php?action=secg,docs_home -> "Released Standards" -> http://www.secg.org/?action=secg,docs_secg -> "SEC1: Elliptic Curve Cryptography version 2.0" -> http://www.secg.org/download/aid-780/sec1-v2.pdf.) > Is there something specific that you believe requires ANSI X9.63 or > IEEE 1363, or some wording that I should clarify? That was the impression I was left with by the text Implementation of this specification requires familiarity with both SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] [IEEE1363] [ANSI-X9.63]. This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms is left to other standards documents. Rereading in light of what you said, I can see that it doesn't quite say that X9.63 and 1363 are necessary; the wording of that section might be improvable - perhaps a note in the second of those paragraphs that [SEC1] is believed sufficient for implementation? I'll try to get around to slogging through converting [SEC1] (which appears to be provided only as another of those damned PDFs) into something usable, and see what I can do with it. (I've found software that can mostly convert PDFs to text, but it's...well, it's got few edges that _aren't_ rough, at the moment.) /~\ 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 2 00:25:38 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 5E0613A6803 for ; Tue, 2 Jun 2009 00:25:38 -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 s6BRzaVBX+g6 for ; Tue, 2 Jun 2009 00:25: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 80E3B3A6C53 for ; Tue, 2 Jun 2009 00:25:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D497463B125; Tue, 2 Jun 2009 07:25:32 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mail.netbsd.org (Postfix) with ESMTP id 1E5D563B10C for ; Tue, 2 Jun 2009 07:25:29 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D2C6B668CF8; Tue, 2 Jun 2009 18:20:17 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rARuARt9IeDR; Tue, 2 Jun 2009 18:20:17 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id AD01A668CC1; Tue, 2 Jun 2009 18:20:17 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7D89319EC0BA; Tue, 2 Jun 2009 18:20:17 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1MBNM9-0002aY-Bo; Tue, 02 Jun 2009 18:20:17 +1200 From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: New Version Notification for draft-green-secsh-ecc-07 In-Reply-To: <200906020416.AAA09897@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Tue, 02 Jun 2009 18:20:17 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: > Implementation of this specification requires familiarity with both > SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] [IEEE1363] > [ANSI-X9.63]. Isn't it X9.62 rather than 9.63 that'd be useful here? It includes a lot more detail on the ECC mechanisms, and has the convenient side-effect that you can test your code on static data (ECDSA certs) before you try it against a server. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 2 04:48:20 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 0B60C3A6F19 for ; Tue, 2 Jun 2009 04:48:20 -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 Wjg9RWb16ABw for ; Tue, 2 Jun 2009 04:48: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 A4BB73A6D2B for ; Tue, 2 Jun 2009 04:48:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 43CBF63B162; Tue, 2 Jun 2009 11:48:13 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id E66E563B16D for ; Tue, 2 Jun 2009 11:48:10 +0000 (UTC) Received: from [115.131.31.54] ([115.131.31.54]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n52BltC1012848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jun 2009 07:48:02 -0400 (EDT) Message-Id: From: Douglas Stebila To: ietf-ssh@NetBSD.org In-Reply-To: <200906020416.AAA09897@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: New Version Notification for draft-green-secsh-ecc-07 Date: Tue, 2 Jun 2009 21:47:52 +1000 References: <20090427001853.AEBF23A68DB@core3.amsl.com> <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> <200906020329.XAA04430@Sparkle.Rodents-Montreal.ORG> <71FF9C19-7F06-42AD-A8B5-D766A67F23CA@stebila.ca> <200906020416.AAA09897@Sparkle.Rodents-Montreal.ORG> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Tue, 02 Jun 2009 07:48:09 -0400 (EDT) X-Miltered: at mailchk-m05 with ID 4A25116B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: clamav-milter 0.95.1 at mailchk-m03 X-Virus-Status: Clean X-UUID: 36faf849-a6f1-4bbb-a113-9949ba43192b Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I will clarify the language and URLs concerning the relevant documents before it goes to RFC. Thanks all. Douglas On 2009-Jun-2, at 2:04 PM, der Mouse wrote: >>> Has anyone here tried to implement [draft-green-secsh-ecc]? >>> I'd like to, but it appears unimplementable without copies of X9.63 >>> and IEEE1363, [...] >> ANSI X9.63 and IEEE 1363 are listed as informative references only. >> I believe that SEC 1, listed as a normative reference, contains all >> information required to implement ECDH, ECDSA, and ECMQV; it is >> freely available from the URL in the references. > > Actually, it is not; it is at least two and I think three links > removed > from the URL in the references. (The shortest path I've found is > http://www.secg.org/ -> "Documents" -> > http://www.secg.org/index.php?action=secg,docs_home -> "Released > Standards" -> http://www.secg.org/?action=secg,docs_secg -> "SEC1: > Elliptic Curve Cryptography version 2.0" -> > http://www.secg.org/download/aid-780/sec1-v2.pdf.) > >> Is there something specific that you believe requires ANSI X9.63 or >> IEEE 1363, or some wording that I should clarify? > > That was the impression I was left with by the text > > Implementation of this specification requires familiarity with both > SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] [IEEE1363] > [ANSI-X9.63]. > > This document is concerned with SSH implementation details; > specification of the underlying cryptographic algorithms is left to > other standards documents. > > Rereading in light of what you said, I can see that it doesn't quite > say that X9.63 and 1363 are necessary; the wording of that section > might be improvable - perhaps a note in the second of those paragraphs > that [SEC1] is believed sufficient for implementation? > > I'll try to get around to slogging through converting [SEC1] (which > appears to be provided only as another of those damned PDFs) into > something usable, and see what I can do with it. (I've found software > that can mostly convert PDFs to text, but it's...well, it's got few > edges that _aren't_ rough, at the moment.) > > /~\ 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 2 09:36:34 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 AD4943A69C8 for ; Tue, 2 Jun 2009 09:36:34 -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 64+TIfOG-qmw for ; Tue, 2 Jun 2009 09:36:33 -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 C046A3A67B7 for ; Tue, 2 Jun 2009 09:36:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 049C563B139; Tue, 2 Jun 2009 16:36:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 AE3D663B125 for ; Tue, 2 Jun 2009 16:36:25 +0000 (UTC) Received: from [10.22.14.169] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n52GaGpW017823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 12:36:21 -0400 (EDT) Date: Tue, 02 Jun 2009 09:36:16 -0700 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: New Version Notification for draft-green-secsh-ecc-07 Message-ID: In-Reply-To: <200906020416.AAA09897@Sparkle.Rodents-Montreal.ORG> References: <20090427001853.AEBF23A68DB@core3.amsl.com> <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> <0A6E21FF527AA78C3D9C05F4@atlantis.pc.cs.cmu.edu> <200906020329.XAA04430@Sparkle.Rodents-Montreal.ORG> <71FF9C19-7F06-42AD-A8B5-D766A67F23CA@stebila.ca> <200906020416.AAA09897@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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Tuesday, June 02, 2009 12:04:03 AM -0400 der Mouse wrote: > >> Has anyone here tried to implement [draft-green-secsh-ecc]? >>> I'd like to, but it appears unimplementable without copies of X9.63 >>> and IEEE1363, [...] >> ANSI X9.63 and IEEE 1363 are listed as informative references only. >> I believe that SEC 1, listed as a normative reference, contains all >> information required to implement ECDH, ECDSA, and ECMQV; it is >> freely available from the URL in the references. > > Actually, it is not; it is at least two and I think three links removed > from the URL in the references. (The shortest path I've found is > http://www.secg.org/ -> "Documents" -> > http://www.secg.org/index.php?action=secg,docs_home -> "Released > Standards" -> http://www.secg.org/?action=secg,docs_secg -> "SEC1: > Elliptic Curve Cryptography version 2.0" -> > http://www.secg.org/download/aid-780/sec1-v2.pdf.) This is true. A better reference would be one that includes a link directly to the document in question, rather than just to the SECG web site. However, a stable reference is important too -- a URL that will stop working is not very useful. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 2 12:56:48 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 3568E3A6FD5 for ; Tue, 2 Jun 2009 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 J6+ZFhoaFpvD for ; Tue, 2 Jun 2009 12:56:47 -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 531283A6F0A for ; Tue, 2 Jun 2009 12:56:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DBA1E63B150; Tue, 2 Jun 2009 19:56:42 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 5347A63B11F for ; Tue, 2 Jun 2009 19:56:38 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n52In7R3025572 for ; Tue, 2 Jun 2009 18:49:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n52In7Kw064124 for ; Tue, 2 Jun 2009 12:49:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n52IdEEq018125; Tue, 2 Jun 2009 13:39:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n52IdEad018124; Tue, 2 Jun 2009 13:39:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 2 Jun 2009 13:39:14 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090602183914.GR29258@Sun.COM> References: <20090410041707.GO1500@Sun.COM> <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> <20090410050235.GT1500@Sun.COM> <200904100611.CAA11368@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904100611.CAA11368@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Apr 10, 2009 at 01:57:37AM -0400, der Mouse wrote: > > BTW, I would love to use the reserved field of KEXINIT to negotiate > > retriable key exchagne (a big deal for gss keyex). > > Why? Why not just have the gss kex define its kex-method-specific > messages so as to permit multiple back-and-forths, retrying as much as > necessary to find something suitable? Because we didn't do that to begin with. We should have. We didn't. > Actually, perhaps the best way to answer that would be to sketch the > semantics for the retryable-kex bit you'd like to define; then I could > probably see what the issue is (or suggest a way that doesn't break > interoperability that badly, using existing facilities). Simple: if key-ex fails, then the client can re-send KEXINIT, the server then responds with its KEXINIT, and the process starts all over. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 2 14:47:49 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 0DE073A69FA for ; Tue, 2 Jun 2009 14:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 aXYcujSFozeQ for ; Tue, 2 Jun 2009 14:47:48 -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 D462E3A690A for ; Tue, 2 Jun 2009 14:47:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A2D863B14E; Tue, 2 Jun 2009 21:47:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 7F26963B114 for ; Tue, 2 Jun 2009 21:47:42 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n52IkoZa029343 for ; Tue, 2 Jun 2009 18:46:50 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n52Iknvv062427 for ; Tue, 2 Jun 2009 12:46:49 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n52Iavqm018115; Tue, 2 Jun 2009 13:36:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n52IatM6018114; Tue, 2 Jun 2009 13:36:55 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 2 Jun 2009 13:36:55 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090602183655.GQ29258@Sun.COM> References: <49DE51A1.6020602@vandyke.com> <200904100049.UAA02426@Sparkle.Rodents-Montreal.ORG> <20090410043105.GR1500@Sun.COM> <200904100555.BAA11295@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904100555.BAA11295@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Apr 10, 2009 at 01:48:01AM -0400, der Mouse wrote: > > Given that key exchange is not retriable I think the best thing to do > > is to ignore [the currently-0 last field of SSH_MSG_KEXNIIT] and > > always place a zero there until we define its meaning. That will > > allow us to use it to negotiate new features when both the client and > > server advertise them (non-zero values). > > Not without breaking interoperability with existing implementations > that check that the field is zero. > > Or do you maintain that there are no such? Or that interoperability > with them doesn't matter? I find the latter severely busted and the > former unlikely, especially since the spec does not even suggest, much > less specify, behaviour for an implementation which encounters a value > for that field that it doesn't understand. I believe that we can get to a day when implementations do the right thing with that reserved field, and in the meantime there's the hated compat bug database. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 3 13:04: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 E3C193A6D0E for ; Wed, 3 Jun 2009 13:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 TrQ5i1YDkl0s for ; Wed, 3 Jun 2009 13:04:53 -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 053C03A6C1B for ; Wed, 3 Jun 2009 13:04:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8B56A63B185; Wed, 3 Jun 2009 20:04:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (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 373E363B13C for ; Wed, 3 Jun 2009 20:04:43 +0000 (UTC) Received: from [129.6.224.231] ([129.6.224.231]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n53IsHrj022483; Wed, 3 Jun 2009 14:54:25 -0400 From: Tim Polk To: ietf-ssh@NetBSD.org In-Reply-To: <20090602183655.GQ29258@Sun.COM> Subject: Moving forward with draft-igoe (Was: Re: applying AES-GCM to secure shell: proposed "tweak") References: <49DE51A1.6020602@vandyke.com> <200904100049.UAA02426@Sparkle.Rodents-Montreal.ORG> <20090410043105.GR1500@Sun.COM> <200904100555.BAA11295@Sparkle.Rodents-Montreal.ORG> <20090602183655.GQ29258@Sun.COM> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 3 Jun 2009 14:54:17 -0400 Cc: Pasi Eronen , draft-igoe-secsh-aes-gcm@tools.ietf.org X-Mailer: Apple Mail (2.930.3) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Folks, I have decided to move forward with publication of draft-igoe-secsh- aes-gcm, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", as an Informational RFC. I have been very pleased by the strong interest on this concluded wg list, and encourage people to continue discussing a general solution. If this moves from the discussion stage to draft development, I would be delighted to sponsor publication of such a draft. However, I have also concluded based on that discussion that draft- igoe-secsh-aes-gcm - in its current form - fills an immediate need. I also do not believe it is the authors' responsibility to develop a generic solution (e.g., negotiating whether the length should be encrypted). That said, I will refocus my near term efforts on clearing the remaining discuss so that the draft can be published. I do not believe this should impact any long term efforts that result from this discussion, and reiterate my support for publication of a generic solution. Thanks, Tim Polk From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 16 12:39: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 0A37E3A6B92 for ; Tue, 16 Jun 2009 12:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ar2KT3lnNg6X for ; Tue, 16 Jun 2009 12:39: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 87F7A3A69A6 for ; Tue, 16 Jun 2009 12:38:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 30A7363B158; Tue, 16 Jun 2009 19:38:47 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 3E9A163B114; Tue, 16 Jun 2009 19:38:46 +0000 (UTC) Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by mail.netbsd.org (Postfix) with ESMTP id D696063B136 for ; Tue, 16 Jun 2009 15:47:54 +0000 (UTC) Received: from MSCS-GH1-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id n5GElpw2010843; Tue, 16 Jun 2009 14:47:52 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 10:47:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EE91.5CFCC47A" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: deaft-gree-sedsh-ecc-08: small correction Date: Tue, 16 Jun 2009 10:47:25 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: deaft-gree-sedsh-ecc-08: small correction Thread-Index: AcnukVzQk2nbTqPGQcqWeBB7dUt7kQ== From: "Igoe, Kevin M." To: X-OriginalArrivalTime: 16 Jun 2009 14:47:25.0785 (UTC) FILETIME=[5D2FC490:01C9EE91] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EE91.5CFCC47A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the Introduction to draft-green-secsh-ecc-08 we find =20 In the interest of adding Suite B algorithms to SSH this document adds three ECC Suite B algorithms to the Secure Shell arsenal: Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie- Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm (ECDSA), as well as utilizing the SHA2 family of secure hash algorithms. Slight error here: ECMQV is no longer part of Suite B. For sake of correctness, I'd suggest something like the following: =20 In the interest of adding Suite B algorithms to SSH this document adds two ECC Suite B algorithms to the Secure Shell arsenal: Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital =20 Signature Algorithm (ECDSA), as well as utilizing the SHA2 family of secure hash algorithms. Additonally, support is provided for Elliptic Curve Menezes-Qu-Vanstone (ECMQV).=20 ------_=_NextPart_001_01C9EE91.5CFCC47A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In the = Introduction=20 to draft-green-= secsh-ecc-08 we=20 find
 
  =20 In the interest of adding Suite B algorithms to SSH this=20 document
   adds three ECC Suite B algorithms to the Secure = Shell=20 arsenal:
   Elliptic Curve Menezes-Qu-Vanstone (ECMQV), = Elliptic=20 Curve Diffie-
   Hellman (ECDH), and Elliptic Curve Digital = Signature Algorithm
   (ECDSA), as well as utilizing the = SHA2=20 family of secure hash
   algorithms.
Slight = error here:=20 ECMQV is no longer part of Suite B.  For sake = of
correctness, I'd=20 suggest something like the following:
 
  =20 In the interest of adding Suite B algorithms to SSH this=20 document
   adds two ECC=20 Suite B algorithms to the Secure Shell arsenal:
   Elliptic = Curve=20 Diffie-Hellman (ECDH), and Elliptic Curve Digital  
   Signature Algorithm (ECDSA), as well as utilizing the = SHA2=20 family
  =20 of secure hash = algorithms. Additonally, support is provided=20 for
      Elliptic Curve Menezes-Qu-Vanstone = (ECMQV).=20
------_=_NextPart_001_01C9EE91.5CFCC47A-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 17 13:29:08 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 62BF528C304 for ; Wed, 17 Jun 2009 13:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=0.222, 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 yFR+9nOV3fAU for ; Wed, 17 Jun 2009 13:29:07 -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 3D11028C2CB for ; Wed, 17 Jun 2009 13:29:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 20FD363B1AC; Wed, 17 Jun 2009 20:29:04 +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 B581F63B172 for ; Wed, 17 Jun 2009 20:29:02 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA19985; Wed, 17 Jun 2009 16:29:01 -0400 (EDT) From: der Mouse Message-Id: <200906172029.QAA19985@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: Wed, 17 Jun 2009 16:23:37 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: ssh1 doc? Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list A while back (a year or two?), I asked if there was any ssh1 protocol documentation, and I was told the closest thing that existed was the ssh1 implementations' source code. Is that (still) true now? I'm asking because I want to write ssh1 compatability support for moussh, so I'll need ssh1 protocol documentation. I'm prepared to read source code and write up documentation if necessary, but I don't see much value in duplicating effort if someone else has already done it. /~\ 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 17 14:44:05 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 35B723A6843 for ; Wed, 17 Jun 2009 14:44:05 -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 WWUeQQlcyAHY for ; Wed, 17 Jun 2009 14:44:04 -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 0AEE53A68F2 for ; Wed, 17 Jun 2009 14:43:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C106C63B1DC; Wed, 17 Jun 2009 21:43:53 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 776BB63B1D3 for ; Wed, 17 Jun 2009 21:43:52 +0000 (UTC) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5HKVAAF010713 for ; Wed, 17 Jun 2009 20:31:11 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLE00800GYHH500@fe-emea-09.sun.com> for ietf-ssh@NetBSD.org; Wed, 17 Jun 2009 21:31:10 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLE00I5PGZY2J60@fe-emea-09.sun.com>; Wed, 17 Jun 2009 21:31:10 +0100 (BST) Date: Wed, 17 Jun 2009 22:30:20 +0200 (CEST) From: Jan Pechanec Subject: Re: ssh1 doc? In-reply-to: <200906172029.QAA19985@Sparkle.Rodents-Montreal.ORG> X-X-Sender: jp161948@rejewski To: der Mouse Cc: ietf-ssh@NetBSD.org Message-id: References: <200906172029.QAA19985@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 17 Jun 2009, der Mouse wrote: >A while back (a year or two?), I asked if there was any ssh1 protocol >documentation, and I was told the closest thing that existed was the >ssh1 implementations' source code. > >Is that (still) true now? I'm asking because I want to write ssh1 >compatability support for moussh, so I'll need ssh1 protocol >documentation. I'm prepared to read source code and write up >documentation if necessary, but I don't see much value in duplicating >effort if someone else has already done it. I'd say that the only documentation is this old draft by Tatu Ylonen: http://www.snailbook.com/docs/protocol-1.5.txt J. -- Jan Pechanec From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 17 14:50:59 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 EE4C228C2D8 for ; Wed, 17 Jun 2009 14:50:59 -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 BLMS7BRzlaXA for ; Wed, 17 Jun 2009 14:50:59 -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 99C9428C2CB for ; Wed, 17 Jun 2009 14:50:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6169763B1E3; Wed, 17 Jun 2009 21:51:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-3.cisco.com", Issuer "Cisco SSCA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 4727463B1DF for ; Wed, 17 Jun 2009 21:51:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.42,239,1243814400"; d="scan'208";a="170828404" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2009 20:42:33 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5HKgX5c008541; Wed, 17 Jun 2009 13:42:33 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5HKgX2c012355; Wed, 17 Jun 2009 20:42:33 GMT Date: Wed, 17 Jun 2009 13:42:33 -0700 (PDT) From: Chris Lonvick To: der Mouse cc: ietf-ssh@netbsd.org Subject: Re: ssh1 doc? In-Reply-To: <200906172029.QAA19985@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <200906172029.QAA19985@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=874; t=1245271353; x=1246135353; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20ssh1=20doc? |Sender:=20; bh=1U70uxsDtf39fLrXAh7wCMd+fgjJ7hQl1enrkMF/XFQ=; b=hFcOJ/l3hjUSkaeIYRsUVR5b4DjSesTdqqu//UkGqJW+J9gJq74lz0n3CW aIxVohxr7S/+qQQxuoKTLm934rRoYRrxjTExaCOIAgRg1VTQTjleDKCoZEmV SaujJkA9Vv; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Hi, There's the "RFC" file in the old distributions. Find a copy of ssh-1.2.30.tar, open it up and see if that's what you want. Regards, Chris On Wed, 17 Jun 2009, der Mouse wrote: > A while back (a year or two?), I asked if there was any ssh1 protocol > documentation, and I was told the closest thing that existed was the > ssh1 implementations' source code. > > Is that (still) true now? I'm asking because I want to write ssh1 > compatability support for moussh, so I'll need ssh1 protocol > documentation. I'm prepared to read source code and write up > documentation if necessary, but I don't see much value in duplicating > effort if someone else has already done it. > > /~\ 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Jun 18 04:52:21 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 5328C3A6C67 for ; Thu, 18 Jun 2009 04:52:21 -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 haVT5iIa5dAr for ; Thu, 18 Jun 2009 04:52:20 -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 48FFA3A68D6 for ; Thu, 18 Jun 2009 04:52:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0C6E263B23B; Thu, 18 Jun 2009 11:52:11 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mail.netbsd.org (Postfix) with ESMTP id DA7E163B183 for ; Thu, 18 Jun 2009 11:52:08 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0D1B541559B; Thu, 18 Jun 2009 22:36:46 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X1Ogy3hhdG7; Thu, 18 Jun 2009 22:36:45 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BE3AD415596; Thu, 18 Jun 2009 22:36:42 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 799FEE0808A; Thu, 18 Jun 2009 22:36:41 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1MHEz3-0004y5-9j; Thu, 18 Jun 2009 22:36:41 +1200 From: Peter Gutmann To: Jan.Pechanec@Sun.COM, mouse@Rodents-Montreal.ORG Subject: Re: ssh1 doc? Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Thu, 18 Jun 2009 22:36:41 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Jan Pechanec writes: >I'd say that the only documentation is this old draft by Tatu Ylonen: > >http://www.snailbook.com/docs/protocol-1.5.txt There's also his 1996 Usenix Security paper: http://www.usenix.org/publications/library/proceedings/sec96/ylonen.html although that's more a high-level overview. Oh, and a question for der Mouse, just out of curiosity, isn't it a bit late to be doing SSHv1? :-). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Jun 18 11:20:15 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 40E443A6A1C for ; Thu, 18 Jun 2009 11:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.79 X-Spam-Level: X-Spam-Status: No, score=-9.79 tagged_above=-999 required=5 tests=[AWL=0.198, 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 M6154Wp4yMkn for ; Thu, 18 Jun 2009 11:20:14 -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 321AA28C43A for ; Thu, 18 Jun 2009 11:20:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7A01263B2B5; Thu, 18 Jun 2009 18:20:17 +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 DD5B063B2B3 for ; Thu, 18 Jun 2009 18:20:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA04540; Thu, 18 Jun 2009 14:20:15 -0400 (EDT) From: der Mouse Message-Id: <200906181820.OAA04540@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, 18 Jun 2009 14:10:53 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: ssh1 doc? In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > Oh, and a question for der Mouse, just out of curiosity, isn't it a > bit late to be doing SSHv1? :-). Well, yes. In some respects, I wouldn't waste machine cycles, much less brain cycles, on ssh1. But at $DAYJOB we have a few internal machines which still are ssh1-only (behind our firewall/NAT, to be sure) that I want to log in to from my desktop. I've been using the same ssh1 implementation moussh replaced as my primary remote-login tool, but (a) I'd like to use a moussh client so that it can share things like keys files and agent access, and (b) making ssh1 compat available in moussh for others in similar situations is something I've been wanting to do for a year or two now. I hardly want to encourage ssh1 use, certainly. I've been unsure just how strongly I want to discourage it; I can imagine a whole spectrum of possibilties, all the way from "don't distribute any ssh1 compat code" to "ship moussh with full automatic ssh1 fallback" - I'm currently tending towards a default of "compiled in but disabled unless a config-file switch is flipped". Another reason is curiosity: I have never learned the ssh1 protocol, and I would like to, even if only to be able to make more-informed judgements about its risks and thus suitability for a given environment. /~\ 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 bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Jun 18 16:13:11 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 9B73F3A6A4B for ; Thu, 18 Jun 2009 16:13:11 -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 cGbTQrmU6hsp for ; Thu, 18 Jun 2009 16:13: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 633603A6826 for ; Thu, 18 Jun 2009 16:13:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DD7AF63B14B; Thu, 18 Jun 2009 23:13:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id 5582963B142 for ; Thu, 18 Jun 2009 23:13:15 +0000 (UTC) Received: from [115.131.47.151] ([115.131.47.151]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n5INCwl3029773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jun 2009 19:13:05 -0400 (EDT) Cc: Message-Id: From: Douglas Stebila To: "Igoe, Kevin M." In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: drasft-green--secsh-ecc-08 support for certificates Date: Fri, 19 Jun 2009 09:12:56 +1000 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Thu, 18 Jun 2009 19:13:13 -0400 (EDT) X-Miltered: at mailchk-m03 with ID 4A3AC9FA.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: clamav-milter 0.95.1 at mailchk-w01 X-Virus-Status: Clean X-UUID: 08a58dd8-9b61-48b2-b06b-b22d25fc7a02 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Hi Kevin, Drafts up until -07 used the language string K_S, server's public host key and/or certificates and then prompted by a comment from Jeffrey Hutzelman I changed it in -08 to what you indicated below, in a desire for more precision in the specification. I sent him another email after your post below to enquire about changing it back, and here's part of the reply I received: > The issue is that K_S must be the server's public host key, in the > format dictated by the negotiated host key algorithm. Just randomly > replacing it with a certificate (or a key in a different format) > will cause interoperability problems. If Kevin wants to use > certificates, he needs to define an SSH public key algorithm whose > public key format includes or permits certificates; currently no > such algorithms are in use (there are formats defined for keys > signed using OpenPGP, but I don't know how widely deployed they are, > and there are no formats defined for X.509 certs). I'm willing to make a change in the draft to allow for the use of certificates, as it is the case that the key exchange method should transport the host public key / certificate in whatever format was decided for it. I'd just like to have an idea in my mind of how an implementation might actually use certificates in an interoperable way in the context of ECDSA/SHA-2, which is presumably what you want when you say Suite B plans to require the use of certificates for both the client and the server. My interpretation is that, when using an ecdsa-sha2-* method for the public key algorithm, an implementation must encode keys in the format specified in the draft, which is as a raw point according to Section 3.1 of the draft. Do you intend for another public key algorithm to specify for the use of ECDSA/SHA-2 keys in X.509 or PGP or some other certificate format? Is it desired that such a specification appear in this draft as well? Or is there a reason that the existing framework of standards already covers it and I'm just not aware of it? Douglas On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote: > Douglas: > > I need to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY > messages. > > Suite B plans to be conservative and require the use of certificates > for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client > (sent in the SSH_MSG_USERAUTH_REQUEST). > > As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST > supports > a "public key blob" for use in transporting the certificate: > > > byte SSH_MSG_USERAUTH_REQUEST > > string user name in ISO-10646 UTF-8 encoding [RFC3629] > > string service name in US-ASCII > > string "publickey" > > boolean FALSE > > string public key algorithm name > > string public key blob > > > > Public key algorithms are defined in the transport layer > > specification [SSH-TRANS]. The 'public key blob' may contain > > certificates. > > > Your SSH_MSG_KEX_ECDH_REPLY message contains the field > > > byte SSH_MSG_KEX_ECDH_REPLY > > string K_S, server's public host key octet string > > string Q_S, server's ephemeral public key octet string > > string the signature on the exchange hash > > string K_S, server's public host key octet string > > > I've been assuming that the K_S string can, like the "public key > Blob" string, contain a certificate. Do you concur with that > interpretaiion? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 13:08:55 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 300F63A6840 for ; Fri, 19 Jun 2009 13:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZIzDvNokmzZz for ; Fri, 19 Jun 2009 13:08:53 -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 B0D943A68B9 for ; Fri, 19 Jun 2009 13:08:52 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0C95363B1BE; Fri, 19 Jun 2009 20:08:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 13FDF63B1B9; Fri, 19 Jun 2009 20:08:55 +0000 (UTC) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.67.1]) by mail.netbsd.org (Postfix) with ESMTP id 221EE63B12C for ; Fri, 19 Jun 2009 12:35:40 +0000 (UTC) Received: from MSCS-GH1-UEA03.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id n5JCZLaq024039; Fri, 19 Jun 2009 12:35:22 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA03.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jun 2009 08:35:33 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F0DA.70485168" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: drasft-green--secsh-ecc-08 support for certificates Date: Fri, 19 Jun 2009 08:35:33 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495C@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: drasft-green--secsh-ecc-08 support for certificates Thread-Index: Acnwal3ahmQHUrw9SSCM8Gdxt31vjAAaGEIA References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> From: "Igoe, Kevin M." To: "Douglas Stebila" Cc: X-OriginalArrivalTime: 19 Jun 2009 12:35:33.0971 (UTC) FILETIME=[709E0230:01C9F0DA] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F0DA.70485168 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We envisioned the server presenting a certificate of its choice (none being one of their options). If the the client doesn't like that cert (untrusted authority, expired, unknown format), they can, if they wish, terminate the attempt to establish a secure shell session. How the client chooses to handle a bad/missing cert is a policy decision left up to the client (or their system adminstrator). Perhaps we could handle this by the addition of a Cert_S string field at the end of the SSH_MSG_KEX_ECDH_REPLY, say byte SSH_MSG_KEX_ECDH_REPLY string K_S, server's public host key octet string string Q_S, server's ephemeral public key octet string string the signature on the exchange hash string K_S, server's public host key octet string string Cert_S, certificate for server's public host=20 where Cert_S is allowed to have length 0 (i.e. Cert_S =3D 00 00 00 00) FYI, a draft defining an X.509 based Suite B cetificate format (draft-solinas-suiteb-cert-03) is in final call. =20 -----Original Message----- From: Douglas Stebila [mailto:douglas@stebila.ca]=20 Sent: Thursday, June 18, 2009 7:13 PM To: Igoe, Kevin M. Cc: ietf-ssh@NetBSD.org Subject: Re: drasft-green--secsh-ecc-08 support for certificates Hi Kevin, Drafts up until -07 used the language string K_S, server's public host key and/or certificates and then prompted by a comment from Jeffrey Hutzelman I changed it in -08 to what you indicated below, in a desire for more precision in the specification. I sent him another email after your post below to enquire about changing it back, and here's part of the reply I received: > The issue is that K_S must be the server's public host key, in the=20 > format dictated by the negotiated host key algorithm. Just randomly=20 > replacing it with a certificate (or a key in a different format) will=20 > cause interoperability problems. If Kevin wants to use certificates,=20 > he needs to define an SSH public key algorithm whose public key format > includes or permits certificates; currently no such algorithms are in=20 > use (there are formats defined for keys signed using OpenPGP, but I=20 > don't know how widely deployed they are, and there are no formats=20 > defined for X.509 certs). I'm willing to make a change in the draft to allow for the use of certificates, as it is the case that the key exchange method should transport the host public key / certificate in whatever format was decided for it. I'd just like to have an idea in my mind of how an implementation might actually use certificates in an interoperable way in the context of ECDSA/SHA-2, which is presumably what you want when you say Suite B plans to require the use of certificates for both the client and the server. My interpretation is that, when using an ecdsa-sha2-* method for the public key algorithm, an implementation must encode keys in the format specified in the draft, which is as a raw point according to Section 3.1 of the draft. Do you intend for another public key algorithm to specify for the use of ECDSA/SHA-2 keys in X.509 or PGP or some other certificate format? Is it desired that such a specification appear in this draft as well? Or is there a reason that the existing framework of standards already covers it and I'm just not aware of it? Douglas On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote: > Douglas: > > I need to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY=20 > messages. > > Suite B plans to be conservative and require the use of certificates=20 > for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client=20 > (sent in the SSH_MSG_USERAUTH_REQUEST). > > As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST=20 > supports a "public key blob" for use in transporting the certificate: > > > byte SSH_MSG_USERAUTH_REQUEST > > string user name in ISO-10646 UTF-8 encoding [RFC3629] > > string service name in US-ASCII > > string "publickey" > > boolean FALSE > > string public key algorithm name > > string public key blob > > > > Public key algorithms are defined in the transport layer=20 > > specification [SSH-TRANS]. The 'public key blob' may contain=20 > > certificates. > > > Your SSH_MSG_KEX_ECDH_REPLY message contains the field > > > byte SSH_MSG_KEX_ECDH_REPLY > > string K_S, server's public host key octet string > > string Q_S, server's ephemeral public key octet string > > string the signature on the exchange hash > > string K_S, server's public host key octet string > > > I've been assuming that the K_S string can, like the "public key Blob" > string, contain a certificate. Do you concur with that=20 > interpretaiion? ------_=_NextPart_001_01C9F0DA.70485168 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: drasft-green--secsh-ecc-08 support for certificates

We = envisioned the server presenting a certificate of its choice (none being = one of their options).  If the the client doesn't like that = cert  (untrusted authority, expired, unknown format), they can, if = they wish, terminate the attempt to establish a secure shell = session.  How the client chooses to handle a bad/missing cert is a = policy decision left up to the client (or their system = adminstrator).

Perhaps we = could handle this by the addition of a Cert_S string field at the end of = the SSH_MSG_KEX_ECDH_REPLY, say

      byte     = SSH_MSG_KEX_ECDH_REPLY
      string   K_S, server's = public host key octet string
      string   Q_S, server's = ephemeral public key octet string
      string   the signature on = the exchange hash
      string   K_S, server's = public host key octet string
      string   Cert_S, = certificate for server's public host

where Cert_S = is allowed to have length 0 (i.e. Cert_S =3D 00 00 00 00)

FYI, a draft = defining an X.509 based Suite B cetificate format = (draft-solinas-suiteb-cert-03) is in final call.
 

-----Original = Message-----
From: Douglas = Stebila [mailto:douglas@stebila.ca]
Sent: Thursday, = June 18, 2009 7:13 PM
To: Igoe, Kevin = M.
Cc: = ietf-ssh@NetBSD.org
Subject: Re: = drasft-green--secsh-ecc-08 support for certificates

Hi = Kevin,

Drafts up until = -07 used the language
        = string K_S, server's public host key = and/or certificates and then prompted by a comment from Jeffrey = Hutzelman I changed it in

-08 to what you = indicated below, in a desire for more precision in the = specification.

I sent him another = email after your post below to enquire about changing it back, and = here's part of the reply I received:

> The issue is = that K_S must be the server's public host key, in the
> format = dictated by the negotiated host key algorithm.  Just randomly =
> replacing it = with a certificate (or a key in a different format) will
> cause = interoperability problems.  If Kevin wants to use certificates, =
> he needs to = define an SSH public key algorithm whose public key format =
> includes or = permits certificates; currently no such algorithms are in
> use (there = are formats defined for keys signed using OpenPGP, but I
> don't know = how widely deployed they are, and there are no formats
> defined for = X.509 certs).

I'm willing to = make a change in the draft to allow for the use of certificates, as it = is the case that the key exchange method should transport the host = public key / certificate in whatever format was decided for = it.

I'd just like to = have an idea in my mind of how an implementation might actually use = certificates in an interoperable way in the context of ECDSA/SHA-2, = which is presumably what you want when you say Suite B plans to require = the use of certificates for both the client and the server.  My = interpretation is that, when using an ecdsa-sha2-* method for the public = key algorithm, an implementation must encode keys in the format = specified in the draft, which is as a raw point according to Section 3.1 = of the draft.  Do you intend for another public key algorithm to = specify for the use of ECDSA/SHA-2 keys in X.509 or PGP or some other = certificate format?  Is it desired that such a specification appear = in this draft as well?  Or is there a reason that the existing = framework of standards already covers it and I'm just not aware of = it?

Douglas

On 2009-Jun-18, at = 5:43 AM, Igoe, Kevin M. wrote:

> = Douglas:
>
>  I need = to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY
> = messages.
>
>  Suite = B plans to be conservative and require the use of certificates =
> for both the = server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client
> (sent in the = SSH_MSG_USERAUTH_REQUEST).
>
> As described = in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST
> supports a = "public key blob" for use in transporting the = certificate:
>
> = >      byte = SSH_MSG_USERAUTH_REQUEST
> = >      string user name in ISO-10646 UTF-8 = encoding [RFC3629]
> = >      string  service name in = US-ASCII
> = >      string  = "publickey"
> = >      boolean FALSE
> = >      string  public key algorithm = name
> = >      string  public key = blob
> = >
> > Public = key algorithms are defined in the transport layer
> > = specification [SSH-TRANS]. The 'public key blob' may contain =
> > = certificates.
>
>
> Your = SSH_MSG_KEX_ECDH_REPLY message contains the field
>
> = >      byte     = SSH_MSG_KEX_ECDH_REPLY
> = >      string   K_S, server's = public host key octet string
> = >      string   Q_S, server's = ephemeral public key octet string
> = >      string   the signature on = the exchange hash
> = >      string   K_S, server's = public host key octet string
>
>
> I've been = assuming that the K_S string can, like the "public key Blob" =
> string, = contain a certificate.  Do you concur with that
> = interpretaiion?

------_=_NextPart_001_01C9F0DA.70485168-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 14:29:09 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 288FB3A6C2A for ; Fri, 19 Jun 2009 14:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=1.286, 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 pTQ2bv2CblIG for ; Fri, 19 Jun 2009 14:29:08 -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 8AE073A6C43 for ; Fri, 19 Jun 2009 14:29:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1B77263B1DC; Fri, 19 Jun 2009 21:29:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 1BD9163B1EF for ; Fri, 19 Jun 2009 21:29:03 +0000 (UTC) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n5JLT0Id003030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jun 2009 17:29:01 -0400 (EDT) Date: Fri, 19 Jun 2009 17:28:58 -0400 From: Jeffrey Hutzelman To: Douglas Stebila , "Igoe, Kevin M." cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: drasft-green--secsh-ecc-08 support for certificates Message-ID: In-Reply-To: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Friday, June 19, 2009 09:12:56 AM +1000 Douglas Stebila wrote: >> > Public key algorithms are defined in the transport layer >> > specification [SSH-TRANS]. The 'public key blob' may contain >> > certificates. >> I've been assuming that the K_S string can, like the "public key >> Blob" string, contain a certificate. Do you concur with that >> interpretaiion? I'm concerned you might be misinterpreting the language in the transport and userauth documents. When the userauth document says "The 'public key block' may contain certificates", it doesn't mean that it is permissible to send a certificate instead of a public key. What it means is that for some SSH public key algorithms, the specified public key format may include or permit use of a certificate. Implementations of key-exchange methods and public-key userauth must send public keys in the format specified for the SSH public key algorithm in use; anything else is not in compliance with the protocol and will not interoperate. In particular, if you "require the use of certificates...", then at least for the existing ssh-rsa and ssh-dsa public key algorithms, and for the ECDSA algorithm specified in the present draft, you are requiring noncompliance with the protocol specification. Now, this could be worked around by defining new public key algorithms whose public key format allows the use of certificates. Some work was done on this before the working group concluded, but it never went very far due to lack of sufficient interest to get it done. Note that even if such new algorithms were to be defined, either by the IETF or by another party, they would likely not be as widely deployed as the current algorithms. Perhaps more importantly, requiring the use of certificates means requiring a mode of operation that is inconsistent with the way people deploy and use SSH in real life. Much use of SSH depends on the "leap of faith" model to avoid the need for pre-established PKI, and a standard which prohibited that mode of operation would make SSH considerably less useful for anyone required to comply. I suggest considering these issues very carefully before introducing such a requirement. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 15:14: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 41C393A68D7 for ; Fri, 19 Jun 2009 15:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 vIYDMp9A8pqk for ; Fri, 19 Jun 2009 15:14:36 -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 6E2753A6A31 for ; Fri, 19 Jun 2009 15:14:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6901963B1CE; Fri, 19 Jun 2009 22:14:19 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 8B68863B1B9 for ; Fri, 19 Jun 2009 22:14:17 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5JMEHEH008844 for ; Fri, 19 Jun 2009 22:14:17 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5JMEG2j009947 for ; Fri, 19 Jun 2009 16:14:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n5JLujpx005494; Fri, 19 Jun 2009 16:56:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5JLuhVb005493; Fri, 19 Jun 2009 16:56:43 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 19 Jun 2009 16:56:43 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Douglas Stebila , "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: drasft-green--secsh-ecc-08 support for certificates Message-ID: <20090619215642.GB1308@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Jun 19, 2009 at 05:28:58PM -0400, Jeffrey Hutzelman wrote: > In particular, if you "require the use of certificates...", then at least > for the existing ssh-rsa and ssh-dsa public key algorithms, and for the > ECDSA algorithm specified in the present draft, you are requiring > noncompliance with the protocol specification. > > Now, this could be worked around by defining new public key algorithms > whose public key format allows the use of certificates. Some work was done > on this before the working group concluded, but it never went very far due > to lack of sufficient interest to get it done. Note that even if such new > algorithms were to be defined, either by the IETF or by another party, they > would likely not be as widely deployed as the current algorithms. +1 > Perhaps more importantly, requiring the use of certificates means requiring > a mode of operation that is inconsistent with the way people deploy and use > SSH in real life. Much use of SSH depends on the "leap of faith" model to > avoid the need for pre-established PKI, and a standard which prohibited > that mode of operation would make SSH considerably less useful for anyone > required to comply. I suggest considering these issues very carefully > before introducing such a requirement. Oh come on Jeff! This, from an author of RFC4462? I think SSHv2 extensions to allow the use of PKIX certificates for host and/or user authentication (and key transport!) would have their place. So too would use of PKIX certificates via PKU2U (hmm, where are we on that?) and the SSHv2 w/ GSS-API extensions (RFC4462). In fact, there's plenty of user interest in using SSHv2 w/ certs. In practice, however, a combination of PKINIT, RFC4462 and the Kerberos V GSS-API mechanism are good enough for a lot of the demand (i.e., PKIX for user certs, not so much for host certs). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 15:25:52 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 1761F3A6C02 for ; Fri, 19 Jun 2009 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 tagged_above=-999 required=5 tests=[AWL=1.179, 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 xXMLlKStinWD for ; Fri, 19 Jun 2009 15:25:50 -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 ADA573A6B47 for ; Fri, 19 Jun 2009 15:25:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C9FA263B1CE; Fri, 19 Jun 2009 22:25:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 2879F63B1C3 for ; Fri, 19 Jun 2009 22:25:56 +0000 (UTC) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n5JMPreX005917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jun 2009 18:25:54 -0400 (EDT) Date: Fri, 19 Jun 2009 18:25:51 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: Douglas Stebila , "Igoe, Kevin M." , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: drasft-green--secsh-ecc-08 support for certificates Message-ID: In-Reply-To: <20090619215642.GB1308@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> <20090619215642.GB1308@Sun.COM> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Friday, June 19, 2009 04:56:43 PM -0500 Nicolas Williams wrote: > On Fri, Jun 19, 2009 at 05:28:58PM -0400, Jeffrey Hutzelman wrote: >> In particular, if you "require the use of certificates...", then at >> least for the existing ssh-rsa and ssh-dsa public key algorithms, and >> for the ECDSA algorithm specified in the present draft, you are >> requiring noncompliance with the protocol specification. >> >> Now, this could be worked around by defining new public key algorithms >> whose public key format allows the use of certificates. Some work was >> done on this before the working group concluded, but it never went very >> far due to lack of sufficient interest to get it done. Note that even >> if such new algorithms were to be defined, either by the IETF or by >> another party, they would likely not be as widely deployed as the >> current algorithms. > > +1 > >> Perhaps more importantly, requiring the use of certificates means >> requiring a mode of operation that is inconsistent with the way people >> deploy and use SSH in real life. Much use of SSH depends on the "leap >> of faith" model to avoid the need for pre-established PKI, and a >> standard which prohibited that mode of operation would make SSH >> considerably less useful for anyone required to comply. I suggest >> considering these issues very carefully before introducing such a >> requirement. > > Oh come on Jeff! This, from an author of RFC4462? > > I think SSHv2 extensions to allow the use of PKIX certificates for host > and/or user authentication (and key transport!) would have their place. So do I, and I would very much like to see that work happen. However, to date, there hasn't been enough interest in doing the work, from people with cycles to do it, for it to actually get done. I hope no one misinterpreted me as saying that no one would be interested in having it; that is certainly not the case. However, my concern is not about defining ways to use certificates with SSH, but about promulgating standards that require their use, -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 15:53:13 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 288BB3A6BF7 for ; Fri, 19 Jun 2009 15:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 G08SfsmV4JwA for ; Fri, 19 Jun 2009 15:53:12 -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 DCDEA3A6B71 for ; Fri, 19 Jun 2009 15:53:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2007863B1BA; Fri, 19 Jun 2009 22:53:18 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id DCA6763B1CE for ; Fri, 19 Jun 2009 22:53:15 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5JMrFuN023504 for ; Fri, 19 Jun 2009 22:53:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5JMrFkY051144 for ; Fri, 19 Jun 2009 16:53:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n5JMZjTt005541; Fri, 19 Jun 2009 17:35:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5JMZjZ6005540; Fri, 19 Jun 2009 17:35:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 19 Jun 2009 17:35:44 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Douglas Stebila , "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: drasft-green--secsh-ecc-08 support for certificates Message-ID: <20090619223544.GE1308@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> <20090619215642.GB1308@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Jun 19, 2009 at 06:25:51PM -0400, Jeffrey Hutzelman wrote: > --On Friday, June 19, 2009 04:56:43 PM -0500 Nicolas Williams > wrote: > >Oh come on Jeff! This, from an author of RFC4462? I had meant to add a smiley there... > >I think SSHv2 extensions to allow the use of PKIX certificates for host > >and/or user authentication (and key transport!) would have their place. > > So do I, and I would very much like to see that work happen. However, to > date, there hasn't been enough interest in doing the work, from people with > cycles to do it, for it to actually get done. I hope no one misinterpreted > me as saying that no one would be interested in having it; that is > certainly not the case. > > However, my concern is not about defining ways to use certificates with > SSH, but about promulgating standards that require their use, RFC4462 doesn't require the use of GSS-API mechanisms for authentication either. If the doc at hand does then you're right, that'd be bad, but it's hard to believe that it does. In fact, I just checked and: a) it does not even provide a way to send certificates, b) much less does it require their use. All the I-D says about certificates is: ... *Verify host key belongs to server. ... *It is recommended that the client verify that the host key sent is the server's host key (using certificates or a local database). ... The "using certificates or a local database" part is repeated once more. You seem to have interpreted that as meaning that the cert should be sent instead of just the key, but section 3.1 (Key Format) makes it clear that that's not the case. I take the above text to mean that the client should look for a certificate whose subject public key matches the server's key. but that's not a trivial operation (since there's no usually no directories that can be searched by subject public key). Therefore I consider that suggestion to be rather useless at best, ambiguous at worst. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 16:39:54 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 225343A6A4E for ; Fri, 19 Jun 2009 16:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.66 X-Spam-Level: X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 pBan6pIwvceT for ; Fri, 19 Jun 2009 16:39:53 -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 440203A693E for ; Fri, 19 Jun 2009 16:39:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 74AF163B1FE; Fri, 19 Jun 2009 23:40:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 234DD63B1FB for ; Fri, 19 Jun 2009 23:39:57 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5JNduBQ007351 for ; Fri, 19 Jun 2009 23:39:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5JNduxS053411 for ; Fri, 19 Jun 2009 17:39:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n5JNTttZ006074; Fri, 19 Jun 2009 18:29:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5JNTsUt006073; Fri, 19 Jun 2009 18:29:54 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 19 Jun 2009 18:29:54 -0500 From: Nicolas Williams To: Douglas Stebila Cc: "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: drasft-green--secsh-ecc-08 support for certificates Message-ID: <20090619232954.GI1308@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Jun 19, 2009 at 09:12:56AM +1000, Douglas Stebila wrote: > > Suite B plans to be conservative and require the use of certificates > >for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client > >(sent in the SSH_MSG_USERAUTH_REQUEST). > > > >As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST > >supports > >a "public key blob" for use in transporting the certificate: I hadn't noticed this earlier. There's no way to "require" the use of certificates for either the server, nor the client host, nor the client user, in SSHv2 _today_ with the existing SSHv2 algorithm names and specs. To send a cert ina public key blob slot would not interoperate. The thing to do is to revive the SSHv2 w/ PKIX document(s) and progress them. That means adding new SSHv2 host and hostbased/pubkey user authentication algorithm names that send certs (and OSCP responses, ...). Alternatively push for completion of PKU2U and use that via SSHv2 w/ GSS-API key exchange and/or userauth. Once those are done, requiring the use of certificates with SSHv2, using those extensions, in any environment would be fine. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 17:19:07 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 37AF63A6BC3 for ; Fri, 19 Jun 2009 17:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 QDtqITmX5Ovt for ; Fri, 19 Jun 2009 17:19:06 -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 2B57E3A6BAA for ; Fri, 19 Jun 2009 17:19:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5B2E863B1BA; Sat, 20 Jun 2009 00:19:11 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 2238763B1F3 for ; Sat, 20 Jun 2009 00:19:10 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5JNHaEw017201 for ; Fri, 19 Jun 2009 23:17:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5JNHZXv064399 for ; Fri, 19 Jun 2009 17:17:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n5JN05GC005564; Fri, 19 Jun 2009 18:00:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5JN0561005563; Fri, 19 Jun 2009 18:00:05 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 19 Jun 2009 18:00:05 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Douglas Stebila , "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: drasft-green--secsh-ecc-08 support for certificates Message-ID: <20090619230005.GG1308@Sun.COM> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> <20090619215642.GB1308@Sun.COM> <20090619223544.GE1308@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090619223544.GE1308@Sun.COM> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Ah, seeing the rest of the thread and -07 I get your comments now. I agree, this I-D a) must not provide a way to use ECC PKIX certs without providing a way to use PKIX certs generally, and if past efforts are any guide, that will take some effort, b) must not require use of ECC certs (but if (a) is met the (b) is implied. Sorry. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jun 19 22:21: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 D5BA13A6A0A for ; Fri, 19 Jun 2009 22:21: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=[AWL=0.000, 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 qO15xHLZziVi for ; Fri, 19 Jun 2009 22:21: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 F16313A6920 for ; Fri, 19 Jun 2009 22:21:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3828963B1F8; Sat, 20 Jun 2009 05:21:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id DAC0163B109 for ; Sat, 20 Jun 2009 05:21:04 +0000 (UTC) Received: from [115.131.25.5] ([115.131.25.5]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n5K5KnQF008478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Jun 2009 01:20:56 -0400 (EDT) Cc: Message-Id: From: Douglas Stebila To: "Igoe, Kevin M." In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495C@MSIS-GH1-UEA06.corp.nsa.gov> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: drasft-green--secsh-ecc-08 support for certificates Date: Sat, 20 Jun 2009 15:20:46 +1000 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> <80F9AC969A517A4DA0DE3E7CF74CC1BB03495C@MSIS-GH1-UEA06.corp.nsa.gov> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Sat, 20 Jun 2009 01:21:03 -0400 (EDT) X-Miltered: at minos with ID 4A3C71B1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: clamav-milter 0.95.1 at mailchk-w03 X-Virus-Status: Clean X-UUID: 8c5d11ce-9891-45df-8da4-931903c3ba4f Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Based on the discussion on the mailing list over the last few days, it appears to me that, in the context of draft-green-secsh-ecc, certificates are presently not supported. A future document on using X.509 or other certificates in SSH may appear, and this document should avoid hindering such a development, but that it is beyond the scope of this draft. At this point, my intentions are to: 1) Have the language regarding K_S in ECDH and ECMQV to read as follows: string K_S, server's public host key to allow for compatibility with any public host key definition, including any future document that may use X.509 certificates. 2) Remove the possible ambiguity in the following text > *It is recommended that the client verify that the host key sent > is the server's host key (using certificates or a local database). as noted by Nicolas Williams by changing it to read *It is recommended that the client verify that the host key sent is the server's host key (for example, using a local database). On the issue of X.509 certificates in SSH, this does seem like a reasonable thing to have standardized. Having looked at what I think is the X.509 in SSH draft http://tools.ietf.org/html/draft-ietf-secsh-x509-03 I am surprised that it did not progress, as it seems relatively complete. If there is interest in seeing it revived and the original authors are unable/unwilling to carry on with the document, I am willing to do so. Douglas On 2009-Jun-20, at 8:35 AM, Nicolas Williams wrote: > All the I-D says about certificates is: > > ... > *Verify host key belongs to server. > ... > *It is recommended that the client verify that the host key sent is > the server's host key (using certificates or a local database). ... > > The "using certificates or a local database" part is repeated once > more. > > You seem to have interpreted that as meaning that the cert should be > sent instead of just the key, but section 3.1 (Key Format) makes it > clear that that's not the case. > > I take the above text to mean that the client should look for a > certificate whose subject public key matches the server's key. but > that's not a trivial operation (since there's no usually no > directories > that can be searched by subject public key). Therefore I consider > that > suggestion to be rather useless at best, ambiguous at worst. On 2009-Jun-19, at 10:35 PM, Igoe, Kevin M. wrote: > We envisioned the server presenting a certificate of its choice > (none being one of their options). If the the client doesn't like > that cert (untrusted authority, expired, unknown format), they can, > if they wish, terminate the attempt to establish a secure shell > session. How the client chooses to handle a bad/missing cert is a > policy decision left up to the client (or their system adminstrator). > > Perhaps we could handle this by the addition of a Cert_S string > field at the end of the SSH_MSG_KEX_ECDH_REPLY, say > > byte SSH_MSG_KEX_ECDH_REPLY > string K_S, server's public host key octet string > string Q_S, server's ephemeral public key octet string > string the signature on the exchange hash > string K_S, server's public host key octet string > string Cert_S, certificate for server's public host > > where Cert_S is allowed to have length 0 (i.e. Cert_S = 00 00 00 00) > > FYI, a draft defining an X.509 based Suite B cetificate format > (draft-solinas-suiteb-cert-03) is in final call. > > > -----Original Message----- > From: Douglas Stebila [mailto:douglas@stebila.ca] > Sent: Thursday, June 18, 2009 7:13 PM > To: Igoe, Kevin M. > Cc: ietf-ssh@NetBSD.org > Subject: Re: drasft-green--secsh-ecc-08 support for certificates > > Hi Kevin, > > Drafts up until -07 used the language > string K_S, server's public host key and/or certificates and > then prompted by a comment from Jeffrey Hutzelman I changed it in > > -08 to what you indicated below, in a desire for more precision in > the specification. > > I sent him another email after your post below to enquire about > changing it back, and here's part of the reply I received: > > > The issue is that K_S must be the server's public host key, in the > > format dictated by the negotiated host key algorithm. Just randomly > > replacing it with a certificate (or a key in a different format) > will > > cause interoperability problems. If Kevin wants to use > certificates, > > he needs to define an SSH public key algorithm whose public key > format > > includes or permits certificates; currently no such algorithms are > in > > use (there are formats defined for keys signed using OpenPGP, but I > > don't know how widely deployed they are, and there are no formats > > defined for X.509 certs). > > I'm willing to make a change in the draft to allow for the use of > certificates, as it is the case that the key exchange method should > transport the host public key / certificate in whatever format was > decided for it. > > I'd just like to have an idea in my mind of how an implementation > might actually use certificates in an interoperable way in the > context of ECDSA/SHA-2, which is presumably what you want when you > say Suite B plans to require the use of certificates for both the > client and the server. My interpretation is that, when using an > ecdsa-sha2-* method for the public key algorithm, an implementation > must encode keys in the format specified in the draft, which is as a > raw point according to Section 3.1 of the draft. Do you intend for > another public key algorithm to specify for the use of ECDSA/SHA-2 > keys in X.509 or PGP or some other certificate format? Is it > desired that such a specification appear in this draft as well? Or > is there a reason that the existing framework of standards already > covers it and I'm just not aware of it? > > Douglas > > On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote: > > > Douglas: > > > > I need to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY > > messages. > > > > Suite B plans to be conservative and require the use of > certificates > > for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client > > (sent in the SSH_MSG_USERAUTH_REQUEST). > > > > As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST > > supports a "public key blob" for use in transporting the > certificate: > > > > > byte SSH_MSG_USERAUTH_REQUEST > > > string user name in ISO-10646 UTF-8 encoding [RFC3629] > > > string service name in US-ASCII > > > string "publickey" > > > boolean FALSE > > > string public key algorithm name > > > string public key blob > > > > > > Public key algorithms are defined in the transport layer > > > specification [SSH-TRANS]. The 'public key blob' may contain > > > certificates. > > > > > > Your SSH_MSG_KEX_ECDH_REPLY message contains the field > > > > > byte SSH_MSG_KEX_ECDH_REPLY > > > string K_S, server's public host key octet string > > > string Q_S, server's ephemeral public key octet string > > > string the signature on the exchange hash > > > string K_S, server's public host key octet string > > > > > > I've been assuming that the K_S string can, like the "public key > Blob" > > string, contain a certificate. Do you concur with that > > interpretaiion? > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jun 22 09:18:07 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 A751C3A6DFC for ; Mon, 22 Jun 2009 09:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 3Nhep5npSK9e for ; Mon, 22 Jun 2009 09:18:06 -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 AD0DD3A6DFD for ; Mon, 22 Jun 2009 09:18:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F1B5F63B102; Mon, 22 Jun 2009 16:18:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by mail.netbsd.org (Postfix) with ESMTP id 04CC463B101 for ; Mon, 22 Jun 2009 16:18:06 +0000 (UTC) Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id n5MGIZ00009527; Mon, 22 Jun 2009 16:18:35 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jun 2009 12:18:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: drasft-green--secsh-ecc-08 support for certificates Date: Mon, 22 Jun 2009 12:18:03 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495E@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: drasft-green--secsh-ecc-08 support for certificates Thread-Index: AcnxZunjk92wQWujQ8SDv0L3nf/ZIAB4R1Tg References: <80F9AC969A517A4DA0DE3E7CF74CC1BB03495B@MSIS-GH1-UEA06.corp.nsa.gov> <80F9AC969A517A4DA0DE3E7CF74CC1BB03495C@MSIS-GH1-UEA06.corp.nsa.gov> From: "Igoe, Kevin M." To: "Douglas Stebila" Cc: X-OriginalArrivalTime: 22 Jun 2009 16:18:03.0883 (UTC) FILETIME=[05062BB0:01C9F355] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list My primary customers (potential USG users of Suite B) have many applications where their security requirements are best served by integrating the use of certificates into secure shell. It looks like I have just "volunteered" to issue an informational RFC with some new secsh public key algorithms. The new SSH public key algorithm names would be something like x509-ecdsa-sha2-p256 x509-ecdsa-sha2-p384 Naturally I will reuse as much of what is in place as possible. =20 Transporting a certificate from the Server to the Client: I see two options: 1) Defining SSH_MSG_KEX_X509_ECDH_* message formats, virtually=20 identical to the SSH_MSG_KEX_ECDH_* messages save for the addition=20 of a "string CERT_S" field to the KEX REPLY (might remove the K_S field).=20 Sadly this means I'll also need new key excahnge algorithm names=20 (x509-ecdh-sha2-p256, x509-ecdh-sha2-p384) since the KEX, not the host=20 algorithm, determines the format of the KEX messages.=20 2) Define x509-ecdsa* key formats so that the x509_ecc_key_blob has an x509 certificate field (see section 3.1 of draft-green-secsh-ecc-08). Transporting a certificate from the Client to the the Server: It appears to me that the public key blob field in the SSH_MSG_USERAUTH_REQUEST=20 is capable of carrying an X509 certificate. (I believe the public key algorithm=20 controls the format of the key blob, and the SSH_MSG_USERAUTH_REQUEST has a "public key algorithm name" field.) I'd appreciate any feedback before I go too far down this path. (An ounce of prevention etc.) P.S. How the user or client is to deal with invalid, malformed or expired certificates is a policy issue. I intend to allow users to set their own policies for handling these issues. P.P.S. As I mentioned earlier, a draft defining an X.509 based Suite B certificate format (draft-solinas-suiteb-cert-03) is in final call. -----Original Message----- From: Douglas Stebila [mailto:douglas@stebila.ca]=20 Sent: Saturday, June 20, 2009 1:21 AM To: Igoe, Kevin M. Cc: ietf-ssh@NetBSD.org Subject: Re: drasft-green--secsh-ecc-08 support for certificates Based on the discussion on the mailing list over the last few days, it appears to me that, in the context of draft-green-secsh-ecc, certificates are presently not supported. A future document on using X.509 or other certificates in SSH may appear, and this document should avoid hindering such a development, but that it is beyond the scope of this draft. At this point, my intentions are to: 1) Have the language regarding K_S in ECDH and ECMQV to read as follows: string K_S, server's public host key to allow for compatibility with any public host key definition, including any future document that may use X.509 certificates. 2) Remove the possible ambiguity in the following text > *It is recommended that the client verify that the host key sent is=20 > the server's host key (using certificates or a local database). as noted by Nicolas Williams by changing it to read *It is recommended that the client verify that the host key sent is the server's host key (for example, using a local database). On the issue of X.509 certificates in SSH, this does seem like a reasonable thing to have standardized. Having looked at what I think is the X.509 in SSH draft http://tools.ietf.org/html/draft-ietf-secsh-x509-03 I am surprised that it did not progress, as it seems relatively complete. If there is interest in seeing it revived and the original authors are unable/unwilling to carry on with the document, I am willing to do so. Douglas On 2009-Jun-20, at 8:35 AM, Nicolas Williams wrote: > All the I-D says about certificates is: > > ... > *Verify host key belongs to server. > ... > *It is recommended that the client verify that the host key sent is > the server's host key (using certificates or a local database). ... > > The "using certificates or a local database" part is repeated once=20 > more. > > You seem to have interpreted that as meaning that the cert should be=20 > sent instead of just the key, but section 3.1 (Key Format) makes it=20 > clear that that's not the case. > > I take the above text to mean that the client should look for a=20 > certificate whose subject public key matches the server's key. but=20 > that's not a trivial operation (since there's no usually no=20 > directories that can be searched by subject public key). Therefore I=20 > consider that suggestion to be rather useless at best, ambiguous at=20 > worst. On 2009-Jun-19, at 10:35 PM, Igoe, Kevin M. wrote: > We envisioned the server presenting a certificate of its choice (none=20 > being one of their options). If the the client doesn't like that cert > (untrusted authority, expired, unknown format), they can, if they=20 > wish, terminate the attempt to establish a secure shell session. How=20 > the client chooses to handle a bad/missing cert is a policy decision=20 > left up to the client (or their system adminstrator). > > Perhaps we could handle this by the addition of a Cert_S string field=20 > at the end of the SSH_MSG_KEX_ECDH_REPLY, say > > byte SSH_MSG_KEX_ECDH_REPLY > string K_S, server's public host key octet string > string Q_S, server's ephemeral public key octet string > string the signature on the exchange hash > string K_S, server's public host key octet string > string Cert_S, certificate for server's public host > > where Cert_S is allowed to have length 0 (i.e. Cert_S =3D 00 00 00 00) > > FYI, a draft defining an X.509 based Suite B cetificate format > (draft-solinas-suiteb-cert-03) is in final call. > > > -----Original Message----- > From: Douglas Stebila [mailto:douglas@stebila.ca] > Sent: Thursday, June 18, 2009 7:13 PM > To: Igoe, Kevin M. > Cc: ietf-ssh@NetBSD.org > Subject: Re: drasft-green--secsh-ecc-08 support for certificates > > Hi Kevin, > > Drafts up until -07 used the language > string K_S, server's public host key and/or certificates and =20 > then prompted by a comment from Jeffrey Hutzelman I changed it in > > -08 to what you indicated below, in a desire for more precision in =20 > the specification. > > I sent him another email after your post below to enquire about =20 > changing it back, and here's part of the reply I received: > > > The issue is that K_S must be the server's public host key, in the > > format dictated by the negotiated host key algorithm. Just randomly > > replacing it with a certificate (or a key in a different format) =20 > will > > cause interoperability problems. If Kevin wants to use =20 > certificates, > > he needs to define an SSH public key algorithm whose public key =20 > format > > includes or permits certificates; currently no such algorithms are =20 > in > > use (there are formats defined for keys signed using OpenPGP, but I > > don't know how widely deployed they are, and there are no formats > > defined for X.509 certs). > > I'm willing to make a change in the draft to allow for the use of =20 > certificates, as it is the case that the key exchange method should =20 > transport the host public key / certificate in whatever format was =20 > decided for it. > > I'd just like to have an idea in my mind of how an implementation =20 > might actually use certificates in an interoperable way in the =20 > context of ECDSA/SHA-2, which is presumably what you want when you =20 > say Suite B plans to require the use of certificates for both the =20 > client and the server. My interpretation is that, when using an =20 > ecdsa-sha2-* method for the public key algorithm, an implementation =20 > must encode keys in the format specified in the draft, which is as a =20 > raw point according to Section 3.1 of the draft. Do you intend for =20 > another public key algorithm to specify for the use of ECDSA/SHA-2 =20 > keys in X.509 or PGP or some other certificate format? Is it =20 > desired that such a specification appear in this draft as well? Or =20 > is there a reason that the existing framework of standards already =20 > covers it and I'm just not aware of it? > > Douglas > > On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote: > > > Douglas: > > > > I need to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY > > messages. > > > > Suite B plans to be conservative and require the use of =20 > certificates > > for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client > > (sent in the SSH_MSG_USERAUTH_REQUEST). > > > > As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST > > supports a "public key blob" for use in transporting the =20 > certificate: > > > > > byte SSH_MSG_USERAUTH_REQUEST > > > string user name in ISO-10646 UTF-8 encoding [RFC3629] > > > string service name in US-ASCII > > > string "publickey" > > > boolean FALSE > > > string public key algorithm name > > > string public key blob > > > > > > Public key algorithms are defined in the transport layer > > > specification [SSH-TRANS]. The 'public key blob' may contain > > > certificates. > > > > > > Your SSH_MSG_KEX_ECDH_REPLY message contains the field > > > > > byte SSH_MSG_KEX_ECDH_REPLY > > > string K_S, server's public host key octet string > > > string Q_S, server's ephemeral public key octet string > > > string the signature on the exchange hash > > > string K_S, server's public host key octet string > > > > > > I've been assuming that the K_S string can, like the "public key =20 > Blob" > > string, contain a certificate. Do you concur with that > > interpretaiion? > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jun 30 23:02: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 0EA9C28C13F for ; Tue, 30 Jun 2009 23:02:24 -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 BYevJInF50Ce for ; Tue, 30 Jun 2009 23:02: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 370AD28C101 for ; Tue, 30 Jun 2009 23:02:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DE59563B2FC; Wed, 1 Jul 2009 06:02:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0624463B113; Wed, 1 Jul 2009 06:02:41 +0000 (UTC) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by mail.netbsd.org (Postfix) with ESMTP id 82B8B63B111 for ; Tue, 30 Jun 2009 14:57:01 +0000 (UTC) Received: by ewy21 with SMTP id 21so268042ewy.13 for ; Tue, 30 Jun 2009 07:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=f71x1hq8iv2+R6BkXCGLCrvlRmDBgC+/DfyiRjoiDb0=; b=gHapHpOiASAjsovm8bCN0Ik/2EbK4LMu6yP4GtfoZkY9+hjlGHhkcy2P3CB2MKFdiK 5pgu9ATHXI8HzXOWUX1qRZ4BXOevV2ucuUrAmk8cUyX/9pj11KjpdQcTxvke2sYfWlQx h/x/3bOeLuGyL8dyBv4Q64u4tjktVHHxocWhI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wjolo6HPA/giq1diqGmBspSa6Qcjwd8emSJ1VwPQ1O1wabEwutBoafpvB6EWQwhWTX wXqRNSbme4SCVd5uhF8/bfeNMTT0KX2/ePjgXVmOrTcdlGmdXwjzB+i0dfQ+jeXcvUVA DZ6yWLsgB9+Wql1EoDSbxW6mqsRWn3H0c1aLM= MIME-Version: 1.0 Received: by 10.216.20.210 with SMTP id p60mr2417843wep.172.1246373820190; Tue, 30 Jun 2009 07:57:00 -0700 (PDT) Date: Tue, 30 Jun 2009 17:57:00 +0300 Message-ID: <9abd48400906300757i69bbbf31iefacb00ee8fc3659@mail.gmail.com> Subject: sftp open directory From: Andriy Melnyk To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Hi, Could someone explain me the following: SSH File Transfer Protocol draft-ietf-secsh-filexfer-13.txt section 8.1.2. Opening a Directory says: *To enumerate a directory, the client first obtains a handle and then issues directory read requests. When enumeration is complete, the handle MUST be closed.* Is it mean that when server receives twice OPEN_DIR command for the same directory then for the second one it should responds with FXP_STATUS(operation fails) because the first one was not closed with FXP_CLOSE? What is the correct behaviour?