From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 3 08:18:54 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C05B11E820B for ; Tue, 3 Sep 2013 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.906 X-Spam-Level: X-Spam-Status: No, score=-101.906 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iEcPN3ul8F3 for ; Tue, 3 Sep 2013 08:18:49 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 90CA211E81F4 for ; Tue, 3 Sep 2013 08:18:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6A01814A194; Tue, 3 Sep 2013 15:18:37 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1597114A191 for ; Tue, 3 Sep 2013 15:18:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id t3DzNY5O5MQ4 for ; Tue, 3 Sep 2013 15:18:29 +0000 (UTC) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.154.26]) by mail.netbsd.org (Postfix) with ESMTP id 532D914A15D for ; Tue, 3 Sep 2013 15:18:29 +0000 (UTC) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id AA3BD2B1CBF7B; Tue, 3 Sep 2013 08:57:35 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 0F1EA2B1C172A for ; Tue, 3 Sep 2013 08:56:50 -0500 (CDT) Received: from [96.231.225.44] (port=53638 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VGr74-00085q-3w; Tue, 03 Sep 2013 08:57:46 -0500 Message-ID: <5225EAD9.9090307@ieca.com> Date: Tue, 03 Sep 2013 09:57:45 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org, draft-joseph-pkix-p6rsshextension@tools.ietf.org Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt References: <20130623182734.911.43342.idtracker@ietfa.amsl.com> In-Reply-To: <20130623182734.911.43342.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130623182734.911.43342.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - netbsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:53638 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 21 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This draft is going to be on an upcoming IESG telechat (as an ISE submission) and was wondering if somebody could have a look at it and provide comments. Thanks, spt -------- Original Message -------- Subject: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt Date: Sun, 23 Jun 2013 11:27:34 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : P6R's Secure Shell Public Key Subsystem Author(s) : Mark Joseph Jim Susoy Filename : draft-joseph-pkix-p6rsshextension-03.txt Pages : 10 Date : 2013-06-23 Abstract: The Secure Shell Public Key Subsystem protocol defines a key distribution protocol to provision an SSH server with user's public keys. However, that protocol is limited to provisioning an SSH server. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport. The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, KMIP, SNMP). The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace). Rights to manage keys and certificates in a specific namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-joseph-pkix-p6rsshextension There's also a htmlized version available at: http://tools.ietf.org/html/draft-joseph-pkix-p6rsshextension-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-joseph-pkix-p6rsshextension-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 3 10:15:19 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A438A21E804B for ; Tue, 3 Sep 2013 10:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPmjfWJsl-Fh for ; Tue, 3 Sep 2013 10:15:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3E21E804E for ; Tue, 3 Sep 2013 10:15:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C886F14A1A2; Tue, 3 Sep 2013 17:15:10 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A363714A1AB for ; Tue, 3 Sep 2013 17:15:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id dvH__Lj_OLGL for ; Tue, 3 Sep 2013 17:15:02 +0000 (UTC) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id EBDC814A1A2 for ; Tue, 3 Sep 2013 17:15:00 +0000 (UTC) Received: from mail93-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE025.bigfish.com (10.236.130.88) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 17:14:59 +0000 Received: from mail93-co9 (localhost [127.0.0.1]) by mail93-co9-R.bigfish.com (Postfix) with ESMTP id AB7AC2400C8; Tue, 3 Sep 2013 17:14:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213;KIP:(null);UIP:(null);IPV:NLI;H:AM2PRD0710HT002.eurprd07.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: -13 X-BigFish: PS-13(zz9371I936eI542I1432I4015I9a6kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail93-co9 (localhost.localdomain [127.0.0.1]) by mail93-co9 (MessageSwitch) id 1378228498275291_21573; Tue, 3 Sep 2013 17:14:58 +0000 (UTC) Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.242]) by mail93-co9.bigfish.com (Postfix) with ESMTP id 3D7EE980057; Tue, 3 Sep 2013 17:14:58 +0000 (UTC) Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 17:14:57 +0000 Received: from DBXPRD0411HT002.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 17:14:51 +0000 Message-ID: <026a01cea8c8$f82ac080$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Turner , , References: <20130623182734.911.43342.idtracker@ietfa.amsl.com> <5225EAD9.9090307@ieca.com> Subject: Re: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt Date: Tue, 3 Sep 2013 18:13:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list A brief look makes me think that more work i needed. - Certifcate sometimes has two i, sometimes one i - why list-certificates with a hyphen and listnamespaces without? -" This document defines version 3 of the new protocol. We are using version 3 so that it can be backward compatible with the protocol defined by RFC 4819 [1]. " Um, seems a bit like namespace squatting which seems improper in an Informational RFC - " Examples of possible "certificate format name" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss". " I would expect interoperability to require a defined list, the sort of thing that IANA does rather well. Also, the names would be more recognisable if there were something that said certificate, rather than key types, eg cert-pgp-sign-rsa - what happens if a removed certificate is in use? I am used to key replacement protocols that have well-defined procedures about what overlap there is and how it is managed. A bald replace seems dodgy. - is there any constraint about the relationship between a certificate and the one that is replacing it? should the new one have anything in common with the old, should it be more secure for some meaning of that term? To me, managing certificates should be more heavyweight than managing public keys. Tom Petch ----- Original Message ----- From: "Sean Turner" To: ; Sent: Tuesday, September 03, 2013 2:57 PM Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt > This draft is going to be on an upcoming IESG telechat (as an ISE > submission) and was wondering if somebody could have a look at it and > provide comments. > > Thanks, > > spt > > -------- Original Message -------- > Subject: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt > Date: Sun, 23 Jun 2013 11:27:34 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : P6R's Secure Shell Public Key Subsystem > Author(s) : Mark Joseph > Jim Susoy > Filename : draft-joseph-pkix-p6rsshextension-03.txt > Pages : 10 > Date : 2013-06-23 > > Abstract: > The Secure Shell Public Key Subsystem protocol defines a key > distribution > protocol to provision an SSH server with user's public keys. However, > that protocol is limited to provisioning an SSH server. This document > describes a new protocol that builds on the protocol defined in RFC 4819 > to allow the provisioning of keys and certificates to a server using the > SSH transport. > > The new protocol allows the calling client to organize > keys and certificates in different namespaces on a server. These > namespaces can be used by the server to allow a client to configure > any application running on the server (e.g., SSH, KMIP, SNMP). > > The new protocol provides a server-independent mechanism for clients > to add public keys, remove public keys, add certificates, remove > certificates, and list the current set of keys and certificates known by > the server by namespace (e.g., list all public keys in the SSH > namespace). > > Rights to manage keys and certificates in a specific namespace are > specific and limited to the authorized user and are defined as part of > the server's implementation. The described protocol is backward > compatible to version 2 defined by RFC 4819. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-joseph-pkix-p6rsshextension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-joseph-pkix-p6rsshextension-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-joseph-pkix-p6rsshextension-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 5 08:15:56 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CB621E80C3 for ; Thu, 5 Sep 2013 08:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CERA5nmppAkp for ; Thu, 5 Sep 2013 08:15:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id EB19C21E80D6 for ; Thu, 5 Sep 2013 08:15:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2B9A714A1FF; Thu, 5 Sep 2013 15:15:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6188814A1F8 for ; Thu, 5 Sep 2013 15:15:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id XDjA52dmnr77 for ; Thu, 5 Sep 2013 15:15:23 +0000 (UTC) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 73B9414A1DE for ; Thu, 5 Sep 2013 15:15:23 +0000 (UTC) Received: from mail47-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE008.bigfish.com (10.236.130.71) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 15:00:18 +0000 Received: from mail47-co9 (localhost [127.0.0.1]) by mail47-co9-R.bigfish.com (Postfix) with ESMTP id 1624B6C0286; Thu, 5 Sep 2013 15:00:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197;KIP:(null);UIP:(null);IPV:NLI;H:DBXPRD0710HT004.eurprd07.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I936eI542I1432I1418I4015I9a6kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail47-co9 (localhost.localdomain [127.0.0.1]) by mail47-co9 (MessageSwitch) id 1378393215739374_21887; Thu, 5 Sep 2013 15:00:15 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.241]) by mail47-co9.bigfish.com (Postfix) with ESMTP id 9F4ACC8004F; Thu, 5 Sep 2013 15:00:15 +0000 (UTC) Received: from DBXPRD0710HT004.eurprd07.prod.outlook.com (157.56.253.197) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 15:00:14 +0000 Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.79.167) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 14:59:57 +0000 Message-ID: <02eb01ceaa48$72cc9360$4001a8c0@gateway.2wire.net> From: t.petch To: Mark Joseph , Sean Turner , , References: <20130905010148.4230e040@mail.p6r.com> Subject: Re: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt Date: Thu, 5 Sep 2013 15:58:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Tom Petch ----- Original Message ----- From: "Mark Joseph" To: "t.petch" ; "Sean Turner" ; ; Sent: Thursday, September 05, 2013 2:01 AM From: t.petch [mailto:ietfc@btconnect.com] To: Sean Turner [mailto:turners@ieca.com], ietf-ssh@NetBSD.org, draft-joseph-pkix-p6rsshextension@tools.ietf.org Sent: Tue, 03 Sep 2013 10:13:20 -0800 A brief look makes me think that more work i needed. - Certifcate sometimes has two i, sometimes one i Sorry but this is not clear, can you please explain. 3.1 SSH_PUBLICKEY_CERTIFCATE_ALREADY_PRESENT 4.1 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT. e,g, - why list-certificates with a hyphen and listnamespaces without? Yes we could make that change thought I don't see how it is really significant. the presence and absence of the hyphen will just cause coders, users and everyone else to make mistakes, forgetting that it is sometimes there and sometimes not. Technically it makes no difference; in terms of producing a robust protocol, it does -" This document defines version 3 of the new protocol. We are using version 3 so that it can be backward compatible with the protocol defined by RFC 4819 [1]. " Um, seems a bit like namespace squatting which seems improper in an Informational RFC Our document actually defines a totally separate protocol from RFC 4819. In section 3 of our document we state that we use a different subsystem name: "publickey@p6r.com". We can start the version number at anything. The benefit of starting with Version 3 is that software used to build RFC 4819 implemenations could be extended easily to add the functionality we have defined (since that is what we did). The IETF has produced a Standards Track V2 - I expect the numbers 3, 4, 5 etc to be implicitly at least reserved for IETF Standard Track use, not to be used for a private protocol, even if it does appear in an RFC. And since it is 'totally separate', then the use of 3 seems inappropriate. With other, more recent protocols, fields like this have a defined range for IETF Standards and a separate one for other variants. - " Examples of possible "certificate format name" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss". " I would expect interoperability to require a defined list, the sort of thing that IANA does rather well. Also, the names would be more recognisable if there were something that said certificate, rather than key types, eg cert-pgp-sign-rsa A previous reviewer had us add the PGP reference since it comes from RFC 4253 SSH Transport layer protocol (Section 6 Public Key Algorithms). Frankly I don't see the benefit of doing an IANA of certificate types for this RFC since there has to be an existing one already for X509 and PGP certs. Seems redundant. I am surprised by this. Interoperability, which is a usual requirement for an IETF protocol, requires that different implementors come up with solutions that can interwork, which means that they know what values of what parameters may be encountered, and what they mean. An undefined list of potential certificate types seems not to meet that requirement. - what happens if a removed certificate is in use? I am used to key replacement protocols that have well-defined procedures about what overlap there is and how it is managed. A bald replace seems dodgy. In reality, systems will use a key or cert for an existing session even if it gets deleted since it has already been loaded into the protocol software (e.g., openSSL) Any new session that tries to use the key or cert while it is being changed should not be able to. This is am implementation on the server side and not appropriate for a protocol definition. If we add that it cannot be deleted while in use then likely it can be held far longer than desired. An administrator who wants or even needs to remove a cert should be able to do so immediately for all new sessions. I find the Security Considerations weak, by the standards of 2013, and this is an area which I think that they should explore, pointing out the dangers. - is there any constraint about the relationship between a certificate and the one that is replacing it? should the new one have anything in common with the old, should it be more secure for some meaning of that term? To me, managing certificates should be more heavyweight than managing public keys. Interesting point but I don't see the relevance to this work. All we are describing is a mechanism to modify both keys and certificates. What you mention seems like a discussion of what sits on top of our mechanism. If you look at KMIP the server can define policies and yet KMIP is a much more than what we describe. I find the Security Considerations weak, by the standards of 2013, and this is an area which I think that they should explore, pointing out the dangers. Certificates are the crux of much security so replacing one by another seems like replacing the foundation stone of a building and whilst you may only be manufacturing the crowbar that makes this possible, I think that, in these times, it behoves you to point out that doing so may cause the building to collapase on you. Tom Petch ----- Original Message ----- From: "Sean Turner" To: ; Sent: Tuesday, September 03, 2013 2:57 PM Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt > This draft is going to be on an upcoming IESG telechat (as an ISE > submission) and was wondering if somebody could have a look at it and > provide comments. > > Thanks, > > spt > > -------- Original Message -------- > Subject: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt > Date: Sun, 23 Jun 2013 11:27:34 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : P6R's Secure Shell Public Key Subsystem > Author(s) : Mark Joseph > Jim Susoy > Filename : draft-joseph-pkix-p6rsshextension-03.txt > Pages : 10 > Date : 2013-06-23 > > Abstract: > The Secure Shell Public Key Subsystem protocol defines a key > distribution > protocol to provision an SSH server with user's public keys. However, > that protocol is limited to provisioning an SSH server. This document > describes a new protocol that builds on the protocol defined in RFC 4819 > to allow the provisioning of keys and certificates to a server using the > SSH transport. > > The new protocol allows the calling client to organize > keys and certificates in different namespaces on a server. These > namespaces can be used by the server to allow a client to configure > any application running on the server (e.g., SSH, KMIP, SNMP). > > The new protocol provides a server-independent mechanism for clients > to add public keys, remove public keys, add certificates, remove > certificates, and list the current set of keys and certificates known by > the server by namespace (e.g., list all public keys in the SSH > namespace). > > Rights to manage keys and certificates in a specific namespace are > specific and limited to the authorized user and are defined as part of > the server's implementation. The described protocol is backward > compatible to version 2 defined by RFC 4819. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-joseph-pkix-p6rsshextension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-joseph-pkix-p6rsshextension-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-joseph-pkix-p6rsshextension-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Sep 6 13:22:54 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734A111E812C for ; Fri, 6 Sep 2013 13:22:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV8dzMAazLwn for ; Fri, 6 Sep 2013 13:22:53 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id AC06911E80F4 for ; Fri, 6 Sep 2013 13:22:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 40EA814A1A8; Fri, 6 Sep 2013 20:22:48 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3FC8B14A15B for ; Fri, 6 Sep 2013 20:22:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id RXBQIY3WWDGw for ; Fri, 6 Sep 2013 20:22:45 +0000 (UTC) Received: from chiark.greenend.org.uk (v6.chiark.greenend.org.uk [IPv6:2001:ba8:1e3::]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6F3F614A158 for ; Fri, 6 Sep 2013 20:22:45 +0000 (UTC) Received: from [172.17.207.18] (helo=araminta.anjou.terraraq.org.uk) by chiark.greenend.org.uk (Debian Exim 4.72 #1) with esmtps (return-path rjk@terraraq.org.uk) id 1VI2YE-0000CX-NQ; Fri, 06 Sep 2013 21:22:42 +0100 Received: from lyonesse.anjou.terraraq.org.uk ([172.17.207.4]) by araminta.anjou.terraraq.org.uk with esmtp (Exim 4.80) (envelope-from ) id 1VI2YD-0003QF-Qa; Fri, 06 Sep 2013 21:22:41 +0100 Message-ID: <522A3991.6020309@terraraq.org.uk> Date: Fri, 06 Sep 2013 21:22:41 +0100 From: Richard Kettlewell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joseph Galbriath CC: "ietf-ssh@NetBSD.org" Subject: Re: SSH File Transfer Protocol - draft-moonesamy-secsh-filexfer-00 References: <9A043F3CF02CD34C8E74AC1594475C734470C9DE@uxcn10-6.UoA.auckland.ac.nz> <6.2.5.6.2.20130712050150.0cd0f7e8@elandnews.com> <33d1f2bbe99843448ee8e993d701b14f@BL2PR08MB004.namprd08.prod.outlook.com> <51E3C0FE.7070806@panix.com> <2900.1373893699@eng-mail01.juniper.net> <51ED561D.4010407@vandyke.com> In-Reply-To: <51ED561D.4010407@vandyke.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 22/07/13 16:56, Joseph Galbriath wrote: > On 2013/07/15 7:08, Mark D. Baushke wrote: >> Hi Folks, >> >> [+cc Richard Kettlewell (see the archives of ietf-ssh >> with this Subject: thread for more information)] >> >> There seems to be a fairly good chart given in >> >> http://www.greenend.org.uk/rjk/sftp/sftpversions.html > > This is a pretty nice summation of the various sftp protocol > versions. > > The extensions mentioned as "Defined in draft-ietf-secsh-filexfer-09.txt > but for some reason not later versions" were moved from the main > filexfer draft to the extensions draft to reduce the size of the main > draft and make it clear that it wasn't necessary to implement them > to have a conforming implementation. (Maybe we should of have done > this with more features, like the block/unblock stuff as well.) > > I just posted a link to that draft in another part of this > thread, but here it is again: > > http://datatracker.ietf.org/doc/draft-ietf-secsh-filexfer-extensions/ Thanks, I've updated my page. ttfn/rjk From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Sep 7 22:22:49 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6921E809B for ; Sat, 7 Sep 2013 22:22:49 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq5smwxfO3xV for ; Sat, 7 Sep 2013 22:22:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 492D321E809A for ; Sat, 7 Sep 2013 22:22:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0E62014A288; Sun, 8 Sep 2013 05:22:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B701414A287; Sun, 8 Sep 2013 05:22:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DB56014A1ED for ; Thu, 5 Sep 2013 16:59:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 75zjCJPC6dUJ for ; Thu, 5 Sep 2013 16:59:51 +0000 (UTC) Received: from mail.p6r.com (mail.p6r.com [173.164.214.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0D5FD14A1EC for ; Thu, 5 Sep 2013 16:59:50 +0000 (UTC) X-Footer: cDZyLmNvbQ== Received: from localhost ([127.0.0.1]) by mail.p6r.com; Thu, 5 Sep 2013 09:59:49 -0700 From: "Mark Joseph" Subject: Re: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt To: "t.petch" , "Sean Turner" , ietf-ssh@NetBSD.org, draft-joseph-pkix-p6rsshextension@tools.ietf.org Organization: P6R, Inc In-Reply-To: <02eb01ceaa48$72cc9360$4001a8c0@gateway.2wire.net> Message-ID: <20130905165949.4ca55b01@mail.p6r.com> Date: Thu, 05 Sep 2013 09:59:49 -0700 X-User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------9b6fd00d872bafe689f6cb297aeaa4d4" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. -------------9b6fd00d872bafe689f6cb297aeaa4d4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable - why list-certificates with a hyphen and listnamespaces without= =3F =20 Yes we could make that change thought I don't see how it is really significant. =20 the presence and absence of the hyphen will just cause coders, users a= nd everyone else to make mistakes, forgetting that it is sometimes there and sometimes not. Technically it makes no difference; in terms of producing a robust protocol, it does I don't mind making this change as it is minor, however, I doubt it wi= ll save an coding errors. -" This document defines version 3 of the new protocol. We are usi= ng version 3 so that it can be backward compatible with the protocol defined by RFC 4819 [1]. " Um, seems a bit like namespace squatting which seems improper in a= n Informational RFC =20 Our document actually defines a totally separate protocol from RFC 481= 9. In section 3 of our document we state that we use a different subsyste= m name: =20 "publickey@p6r.com". We can start the version number at anything. The benefit of starting with Version 3 is that software used to build RFC 4819 implemenations could be extended easily to add the functionality we have defined (since that is what we did). =20 The IETF has produced a Standards Track V2 - I expect the numbers 3, 4= , 5 etc to be implicitly at least reserved for IETF Standard Track use, not to be used for a private protocol, even if it does appear in an RF= C. And since it is 'totally separate', then the use of 3 seems inappropriate. With other, more recent protocols, fields like this ha= ve a defined range for IETF Standards and a separate one for other variants. Again we are defining a new protocol one where the subsystem name is p= rivate to us and thus it is easy to start at any number. Since this is not related directly to any other protocol is it not relev= ant what version number we start at. So in this issue I disagree with the reviewers comment. - " Examples of possible "certificate format name" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss". " I would expect interoperability to require a defined list, the sort = of thing that IANA does rather well. Also, the names would be more recognisable if there were something that said certificate, rather than key types, eg cert-pgp-sign-rsa A previous reviewer had us add the PGP reference since it comes from R= FC 4253 SSH Transport layer protocol (Section 6 Public Key Algorithms). Frankly I don't see the benefit of doing an IANA of certificate types for this RFC since there has to be an existing one already for X509 an= d PGP certs. Seems redundant. =20 I am surprised by this. Interoperability, which is a usual requiremen= t for an IETF protocol, requires that different implementors come up wit= h solutions that can interwork, which means that they know what values o= f what parameters may be encountered, and what they mean. An undefined list of potential certificate types seems not to meet that requirement= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 17 13:32:31 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F9F11E8196 for ; Tue, 17 Sep 2013 13:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Icl2XKK4u44I for ; Tue, 17 Sep 2013 13:32:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id DE93921F8F3C for ; Tue, 17 Sep 2013 13:32:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4206A14A132; Tue, 17 Sep 2013 20:32:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2AA3514A12E for ; Tue, 17 Sep 2013 20:32:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id CprMrMqyDeVp for ; Tue, 17 Sep 2013 20:32:18 +0000 (UTC) Received: from pandora.lunarmania.com (pandora.lunarmania.com [67.210.98.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A333E14A11B for ; Tue, 17 Sep 2013 20:32:18 +0000 (UTC) Received: from haird1 by pandora.lunarmania.com with local (Exim 4.80.1) (envelope-from ) id 1VLzyE-0006vc-Fi for ietf-ssh@netbsd.org; Tue, 17 Sep 2013 11:25:54 -0700 To: ietf-ssh@netbsd.org Subject: Hey, I am Finch! MIME-Version: 1.0 From: Finch Ojwvs Reply-To: Finch Ojwvs Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; Message-Id: Date: Tue, 17 Sep 2013 11:25:54 -0700 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pandora.lunarmania.com X-AntiAbuse: Original Domain - netbsd.org X-AntiAbuse: Originator/Caller UID/GID - [32145 32147] / [47 12] X-AntiAbuse: Sender Address Domain - pandora.lunarmania.com X-Get-Message-Sender-Via: pandora.lunarmania.com: authenticated_id: haird1/from_h Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list How is it going, I'm Finch. I am looking for some fun in here, I mean I need a man to spend time together. I enjoy listening to music, playing different games, watching thriller films, I also really like rope jumping! What would u think if I'd say that I love sex?) I really do. You do love sex, don't you?) Maybe we'll like each other, right?) Anyway, write me back. It is interesting to hear what you got to say about all of that)