From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 11 07:18:53 2010 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 A91FE3A680D for ; Thu, 11 Mar 2010 07:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 eDgoPNPs607q for ; Thu, 11 Mar 2010 07:18:52 -0800 (PST) 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 183FE3A6A1E for ; Thu, 11 Mar 2010 07:15:59 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1BAEF63B216; Thu, 11 Mar 2010 15:15:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-5.cisco.com", Issuer "Cisco SSCA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id C759963B236 for ; Thu, 11 Mar 2010 15:15:19 +0000 (UTC) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAMOXmEurRN+J/2dsb2JhbACPFQGLS3OkSJhwhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,620,1262563200"; d="scan'208";a="164239765" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2010 15:15:17 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2BFFHmU016172 for ; Thu, 11 Mar 2010 15:15:17 GMT Date: Thu, 11 Mar 2010 07:15:17 -0800 (PST) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Progress on draft-igoe-secsh-x509v3? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, I havn't seen too much discussion on the list about the ID lately. Is it ready to go to the IESG? If there is still some grey areas that need to be addressed, what do people think of getting together in Anaheim to go over them? Regards, Chris From info@web.org Fri Mar 12 04:46:22 2010 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 013E43A6826 for ; Fri, 12 Mar 2010 04:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.225 X-Spam-Level: ** X-Spam-Status: No, score=2.225 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, RCVD_IN_SORBS_WEB=0.619] 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 tmhDxZYHg2Ya for ; Fri, 12 Mar 2010 04:46:21 -0800 (PST) Received: from mail.sliven.bg (mail.sliven.bg [87.121.77.67]) by core3.amsl.com (Postfix) with ESMTP id E4D8A3A6824 for ; Fri, 12 Mar 2010 04:46:19 -0800 (PST) Received: from mail.sliven.bg (localhost [127.0.0.1]) by mail.sliven.bg (8.14.1/8.14.1) with ESMTP id o2CEU4l3000358; Fri, 12 Mar 2010 15:30:04 +0100 Received: from 212.116.219.150 (proxying for 196.46.246.21) (SquirrelMail authenticated user europedirect) by mail.sliven.bg with HTTP; Fri, 12 Mar 2010 14:30:07 -0000 (GMT) Message-ID: <37128.212.116.219.150.1268404207.squirrel@mail.sliven.bg> Date: Fri, 12 Mar 2010 14:30:07 -0000 (GMT) Subject: Dear Web-Mail Account Owner From: "Web-Mail Admin" Reply-To: webupdatet_team@mail2consultant.com User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=windows-1251 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Dear Account Owner: It has come to our notice that your email has not passed the verification/Update process that we are presently working on.We are currently upgrading our data base and e-mail account center .We are deleting all Old Web mail email account to create more space for new accounts. To prevent your account from closing you will have to update it so that we will know that it's a present used account. To complete your account re-confirmation, you must reply to this email immediately and enter your account details as requested below. *********************************************** Email User-name :........ ..... EMAIL Password :............... Date of Birth :............... Country or Territory :........ ************************************************ ****IMPORTANT : This updating is compulsory as a result of our recent server changes. If you fail to update your email address you will soon be unable to receive/send mails.Also your email will not be equipped with the latest anti-virus system in our new servers. This will make your email and PC vulnerable to virus attacks from the internet. **** HOW TO UPDATE: To update simply reply the above to upgrading admin as appropriate.Failure to do so immediately will lead to SUSPENSION OF YOUR ACCOUNT. Thanks for your co-operation, Web-mail Administrator WEB MAIL BETA. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 11:39:18 2010 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 062F93A69F0 for ; Tue, 16 Mar 2010 11:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 FNK7N1SwHP1R for ; Tue, 16 Mar 2010 11:39:16 -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 1199E3A69C9 for ; Tue, 16 Mar 2010 11:38:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 36CF163B266; Tue, 16 Mar 2010 18:38:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 B5FC063B209 for ; Tue, 16 Mar 2010 18:38:45 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 09B3CC4AB7; Wed, 17 Mar 2010 04:19:34 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 8DD36C4AED for ; Wed, 17 Mar 2010 04:19:28 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 3DB395316E; Wed, 17 Mar 2010 04:19:28 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 3C71D5278B for ; Wed, 17 Mar 2010 04:19:28 +1100 (EST) Date: Wed, 17 Mar 2010 04:19:28 +1100 (EST) From: Damien Miller To: ietf-ssh@netbsd.org Subject: OpenSSH certified keys Message-ID: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, OpenSSH 5.4p1 introduced a novel, lightweight certificate format for user and host keys. These were designed to reuse SSH wire-encoding and signature primitives to minimise the additional attack surface exposed pre-auth. In particular, we are not comfortable with the complexity (syntactically or sematically) of X.509. Here is the document from the OpenSSH source distribution that describes them (PROTOCOL.certkeys). If there is interested from other implementors in interoperating with these certificates then I'm willing to write this up as an I-D. -d ------------------------ This document describes a simple public-key certificate authentication system for use by SSH. Background ---------- The SSH protocol currently supports a simple public key authentication mechanism. Unlike other public key implementations, SSH eschews the use of X.509 certificates and uses raw keys. This approach has some benefits relating to simplicity of configuration and minimisation of attack surface, but it does not support the important use-cases of centrally managed, passwordless authentication and centrally certified host keys. These protocol extensions build on the simple public key authentication system already in SSH to allow certificate-based authentication. The certificates used are not traditional X.509 certificates, with numerous options and complex encoding rules, but something rather more minimal: a key, some identity information and usage constraints that have been signed with some other trusted key. A sshd server may be configured to allow authentication via certified keys, by extending the existing ~/.ssh/authorized_keys mechanism to allow specification of certification authority keys in addition to raw user keys. The ssh client will support automatic verification of acceptance of certified host keys, by adding a similar ability to specify CA keys in ~/.ssh/known_hosts. Certified keys are represented using two new key types: ssh-rsa-cert-v00@openssh.com and ssh-dss-cert-v00@openssh.com that include certification information along with the public key that is used to sign challenges. ssh-keygen performs the CA signing operation. Protocol extensions ------------------- The SSH wire protocol includes several extensibility mechanisms. These modifications shall take advantage of namespaced public key algorithm names to add support for certificate authentication without breaking the protocol - implementations that do not support the extensions will simply ignore them. Authentication using the new key formats described below proceeds using the existing SSH "publickey" authentication method described in RFC4252 section 7. New public key formats ---------------------- The ssh-rsa-cert-v00@openssh.com and ssh-dss-cert-v00@openssh.com key types take a similar high-level format (note: data types and encoding are as per RFC4251 section 5). The serialised wire encoding of these certificates is also used for storing them on disk. #define SSH_CERT_TYPE_USER 1 #define SSH_CERT_TYPE_HOST 2 RSA certificate string "ssh-rsa-cert-v00@openssh.com" mpint e mpint n uint32 type string key id string valid principals uint64 valid after uint64 valid before string constraints string nonce string reserved string signature key string signature DSA certificate string "ssh-dss-cert-v00@openssh.com" mpint p mpint q mpint g mpint y uint32 type string key id string valid principals uint64 valid after uint64 valid before string constraints string nonce string reserved string signature key string signature e and n are the RSA exponent and public modulus respectively. p, q, g, y are the DSA parameters as described in FIPS-186-2. type specifies whether this certificate is for identification of a user or a host using a SSH_CERT_TYPE_... value. key id is a free-form text field that is filled in by the CA at the time of signing; the intention is that the contents of this field are used to identify the identity principal in log messages. "valid principals" is a string containing zero or more principals as strings packed inside it. These principals list the names for which this certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and usernames for SSH_CERT_TYPE_USER certificates. As a special case, a zero-length "valid principals" field means the certificate is valid for any principal of the specified type. XXX DNS wildcards? "valid after" and "valid before" specify a validity period for the certificate. Each represents a time in seconds since 1970-01-01 00:00:00. A certificate is considered valid if: valid after <= current time < valid before constraints is a set of zero or more key constraints encoded as below. The nonce field is a CA-provided random bitstring of arbitrary length (but typically 16 or 32 bytes) included to make attacks that depend on inducing collisions in the signature hash infeasible. The reserved field is current unused and is ignored in this version of the protocol. signature key contains the CA key used to sign the certificate. The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained" certificates, where the signature key type is a certificate type itself are NOT supported. Note that it is possible for a RSA certificate key to be signed by a DSS CA key and vice-versa. signature is computed over all preceding fields from the initial string up to, and including the signature key. Signatures are computed and encoded according to the rules defined for the CA's public key algorithm (RFC4253 section 6.6 for ssh-rsa and ssh-dss). Constraints ----------- The constraints section of the certificate specifies zero or more constraints on the certificates validity. The format of this field is a sequence of zero or more tuples: string name string data The name field identifies the constraint and the data field encodes constraint-specific information (see below). All constraints are "critical", if an implementation does not recognise a constraint then the validating party should refuse to accept the certificate. The supported constraints and the contents and structure of their data fields are: Name Format Description ----------------------------------------------------------------------------- force-command string Specifies a command that is executed (replacing any the user specified on the ssh command-line) whenever this key is used for authentication. permit-X11-forwarding empty Flag indicating that X11 forwarding should be permitted. X11 forwarding will be refused if this constraint is absent. permit-agent-forwarding empty Flag indicating that agent forwarding should be allowed. Agent forwarding must not be permitted unless this constraint is present. permit-port-forwarding empty Flag indicating that port-forwarding should be allowed. If this constraint is not present then no port forwarding will be allowed. permit-pty empty Flag indicating that PTY allocation should be permitted. In the absence of this constraint PTY allocation will be disabled. permit-user-rc empty Flag indicating that execution of ~/.ssh/rc should be permitted. Execution of this script will not be permitted if this constraint is not present. source-address string Comma-separated list of source addresses from which this certificate is accepted for authentication. Addresses are specified in CIDR format (nn.nn.nn.nn/nn or hhhh::hhhh/nn). If this constraint is not present then certificates may be presented from any source address. $OpenBSD: PROTOCOL.certkeys,v 1.3 2010/03/03 22:50:40 djm Exp $ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 12:00:28 2010 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 711A33A6B70 for ; Tue, 16 Mar 2010 12:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.662 X-Spam-Level: X-Spam-Status: No, score=-4.662 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 qhFEqYiVaC4D for ; Tue, 16 Mar 2010 12:00:27 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8C6A03A6C26 for ; Tue, 16 Mar 2010 12:00:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9CCCE63B279; Tue, 16 Mar 2010 19:00:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet14.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 45F3B63B209 for ; Tue, 16 Mar 2010 19:00:14 +0000 (UTC) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rcsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o2GJ0CX0009516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Mar 2010 19:00:13 GMT Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2GIxnck028743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Mar 2010 18:59:50 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2GIxkEp002547; Tue, 16 Mar 2010 18:59:46 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 90454281268765758; Tue, 16 Mar 2010 11:55:58 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 11:55:57 -0700 Date: Tue, 16 Mar 2010 13:55:53 -0500 From: Nicolas Williams To: Damien Miller Cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100316185552.GP14993@Sun.COM> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4B9FD525.0030,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote: > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > user and host keys. These were designed to reuse SSH wire-encoding and > signature primitives to minimise the additional attack surface exposed > pre-auth. In particular, we are not comfortable with the complexity > (syntactically or sematically) of X.509. > > Here is the document from the OpenSSH source distribution that describes > them (PROTOCOL.certkeys). If there is interested from other implementors > in interoperating with these certificates then I'm willing to write this > up as an I-D. On the one hand I think a simpler PKI than PKIX is always appealing. On the other hand I think that any simpler-than-PKIX PKI spec had better get some things right, foremost, I think, is the OCSP model of revocation instead of CRLs. OCSP is often used in this manner: the user agent gets an OCSP Response for its cert then presents both to relying parties. I like to think of OCSP as a ticketing system not too unlike Kerberos. You start with a long-term key pair and certificate issued by a long-term CA, present it to an "online CA" that issues short-term certificates attesting that long-term ones are still valid, and then you use both certs to authenticate to relying parties. It's also useful, I think, to state all trade-offs explicitly. For example, a certificate might not bear anything like subject and subject alternative names or other data useful for authorization, leaving RPs to handle authorization entirely on their own. Or a certs might not bear names or other such data but a directory might be used to lookup such things using a cert (issuer&serial, whatever) as a lookup key. In the latter case there's a requirement for online infrastructure, much as in the case of OCSP, Kerberos, ... But even a PKI with CRLs requires online infrastructure for CRL distribution. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 12:32:11 2010 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 130F83A69F7 for ; Tue, 16 Mar 2010 12:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 tsBLr2a+e+-0 for ; Tue, 16 Mar 2010 12:32: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 AF9D63A69AC for ; Tue, 16 Mar 2010 12:31:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1AD6F63B255; Tue, 16 Mar 2010 19:32:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from acsinet14.oracle.com (acsinet14.oracle.com [141.146.126.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "acsinet14.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 5A9E763B18D for ; Tue, 16 Mar 2010 19:31:58 +0000 (UTC) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by acsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o2GJVuZi011484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Mar 2010 19:31:57 GMT Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2GJVmdO025575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Mar 2010 19:31:50 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2GJ9e02005361; Tue, 16 Mar 2010 19:31:48 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 90548191268767904; Tue, 16 Mar 2010 12:31:44 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 12:31:43 -0700 Date: Tue, 16 Mar 2010 14:31:39 -0500 From: Nicolas Williams To: Damien Miller Cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100316193139.GV14993@Sun.COM> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4B9FDCA4.0177,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote: > "valid principals" is a string containing zero or more principals as > strings packed inside it. These principals list the names for which this > certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and > usernames for SSH_CERT_TYPE_USER certificates. As a special case, a > zero-length "valid principals" field means the certificate is valid for > any principal of the specified type. XXX DNS wildcards? Er, can usernames contain @domain qualifiers? How should usernames without an @domain qualifier be handled by servers? Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 12:54:13 2010 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 EFFF93A693A for ; Tue, 16 Mar 2010 12:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 oMOou0qA9tRl for ; Tue, 16 Mar 2010 12:54:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3C94E3A67C1 for ; Tue, 16 Mar 2010 12:54:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B777E63B18B; Tue, 16 Mar 2010 19:54:10 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 2DE1463B117 for ; Tue, 16 Mar 2010 19:54:08 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id BE5E8C4AD5; Wed, 17 Mar 2010 06:54:05 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id C7313C4AAB; Wed, 17 Mar 2010 06:54:00 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 224BF5278B; Wed, 17 Mar 2010 06:54:00 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 1BA3A5278A; Wed, 17 Mar 2010 06:54:00 +1100 (EST) Date: Wed, 17 Mar 2010 06:54:00 +1100 (EST) From: Damien Miller To: Nicolas Williams cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: <20100316193139.GV14993@Sun.COM> Message-ID: References: <20100316193139.GV14993@Sun.COM> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 16 Mar 2010, Nicolas Williams wrote: > On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote: > > "valid principals" is a string containing zero or more principals as > > strings packed inside it. These principals list the names for which this > > certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and > > usernames for SSH_CERT_TYPE_USER certificates. As a special case, a > > zero-length "valid principals" field means the certificate is valid for > > any principal of the specified type. XXX DNS wildcards? > > Er, can usernames contain @domain qualifiers? How should usernames > without an @domain qualifier be handled by servers? Presently, usernames are interpreted locally. I'd like to support domain- scoped usernames but deliberate left it out of the initial implementation until I had a chance to gather and think about the requirements some more. I had a couple of ideas on how to make it useful: 1) Support another type "SSH_CERT_TYPE_USER_HOST" that includes the qualifiers 2) Encode domain qualifiers as a certificate constraint 3) Encourage a mapping between principal names encoded in the cert and local usernames to be implemented in the SSH server. I'm leaning towards #3 - having (in OpenSSH-parlance) an "authorized_principals" file that specifies which principals are permitted for an account. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 13:29:48 2010 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 3F22D3A6978 for ; Tue, 16 Mar 2010 13:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 NyU4gF32ErqI for ; Tue, 16 Mar 2010 13:29: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 A95903A696F for ; Tue, 16 Mar 2010 13:29:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0C4A263B117; Tue, 16 Mar 2010 20:29:45 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 49EB763B100 for ; Tue, 16 Mar 2010 20:29:42 +0000 (UTC) Received: from element ([205.217.224.99]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 16 Mar 2010 15:29:03 -0400 Message-ID: From: "denis bider \(Bitvise\)" To: "Nicolas Williams" , "Damien Miller" Cc: References: <20100316185552.GP14993@Sun.COM> In-Reply-To: <20100316185552.GP14993@Sun.COM> Subject: Re: OpenSSH certified keys Date: Tue, 16 Mar 2010 15:29:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I second Nicolas's concern. Your spec doesn't even mention revocation. How is revocation handled? Are the keys expected to be certified only for a very short term? If certification is expected to be for only a very short term, are you putting an infrastructure in place that allows a client to obtain a fresh certificate before it connects? If you are putting such infrastructure in place, do you have a spec for how the client obtains the fresh certificate? Otherwise, if you are planning for these certificates to be long-term, what is your solution for revocation? ----- Original Message ----- From: "Nicolas Williams" To: "Damien Miller" Cc: Sent: Tuesday, March 16, 2010 14:55 Subject: Re: OpenSSH certified keys On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote: > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > user and host keys. These were designed to reuse SSH wire-encoding and > signature primitives to minimise the additional attack surface exposed > pre-auth. In particular, we are not comfortable with the complexity > (syntactically or sematically) of X.509. > > Here is the document from the OpenSSH source distribution that > describes > them (PROTOCOL.certkeys). If there is interested from other > implementors > in interoperating with these certificates then I'm willing to write > this > up as an I-D. On the one hand I think a simpler PKI than PKIX is always appealing. On the other hand I think that any simpler-than-PKIX PKI spec had better get some things right, foremost, I think, is the OCSP model of revocation instead of CRLs. OCSP is often used in this manner: the user agent gets an OCSP Response for its cert then presents both to relying parties. I like to think of OCSP as a ticketing system not too unlike Kerberos. You start with a long-term key pair and certificate issued by a long-term CA, present it to an "online CA" that issues short-term certificates attesting that long-term ones are still valid, and then you use both certs to authenticate to relying parties. It's also useful, I think, to state all trade-offs explicitly. For example, a certificate might not bear anything like subject and subject alternative names or other data useful for authorization, leaving RPs to handle authorization entirely on their own. Or a certs might not bear names or other such data but a directory might be used to lookup such things using a cert (issuer&serial, whatever) as a lookup key. In the latter case there's a requirement for online infrastructure, much as in the case of OCSP, Kerberos, ... But even a PKI with CRLs requires online infrastructure for CRL distribution. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 13:51:10 2010 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 93A2C3A67DA for ; Tue, 16 Mar 2010 13:51:10 -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 P7iOfof4ZMrU for ; Tue, 16 Mar 2010 13:51:09 -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 6F07A3A672E for ; Tue, 16 Mar 2010 13:51:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0611363B117; Tue, 16 Mar 2010 20:51:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id B41C963B104 for ; Tue, 16 Mar 2010 20:51:10 +0000 (UTC) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2GJYYkR015280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 15:34:34 -0400 (EDT) Date: Tue, 16 Mar 2010 15:34:34 -0400 From: Jeffrey Hutzelman To: Damien Miller , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: OpenSSH certified keys Message-ID: <12E8D70369775EC7EE5E2740@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller wrote: > The nonce field is a CA-provided random bitstring of arbitrary length > (but typically 16 or 32 bytes) included to make attacks that depend on > inducing collisions in the signature hash infeasible. Except that you've put it so late in the "certificate" that it's not terribly useful for that purpose against current attacks. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 13:51:31 2010 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 C74693A67DA for ; Tue, 16 Mar 2010 13:51:31 -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 htLbkBdP+ZAv for ; Tue, 16 Mar 2010 13:51:31 -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 0478D3A67BD for ; Tue, 16 Mar 2010 13:51:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 203DA63B135; Tue, 16 Mar 2010 20:51:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 961E463B104 for ; Tue, 16 Mar 2010 20:51:31 +0000 (UTC) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2GJgrTv015503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 15:42:54 -0400 (EDT) Date: Tue, 16 Mar 2010 15:42:53 -0400 From: Jeffrey Hutzelman To: Damien Miller , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: OpenSSH certified keys Message-ID: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller wrote: > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > user and host keys. These were designed to reuse SSH wire-encoding and > signature primitives to minimise the additional attack surface exposed > pre-auth. In particular, we are not comfortable with the complexity > (syntactically or sematically) of X.509. That's unfortunate, because it's what the rest of the world already has as its infrastructure. By not supporting it, you force people to choose between supporting your odd, proprietary, unproven certificate format or not getting to use certificates at all. Guess which one anyone with more than 5 machines is going to choose? OpenSSH would be a lot more useful if it supported the same authentication mechanisms as the rest of the world. > signature key contains the CA key used to sign the certificate. > The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained" > certificates, where the signature key type is a certificate type itself > are NOT supported. Note that it is possible for a RSA certificate key to > be signed by a DSS CA key and vice-versa. This seems like a serious shortcoming. Practically no one uses single-level certificate heirarchies any more; there's nearly always at least one intermediate CA for operational and security reasons. Taking out this feature makes the system less secure. > The name field identifies the constraint and the data field encodes > constraint-specific information (see below). All constraints are > "critical", if an implementation does not recognise a constraint > then the validating party should refuse to accept the certificate. > ... > permit-X11-forwarding empty Flag indicating that X11 forwarding > should be permitted. X11 forwarding > will be refused if this constraint > is absent. This is a poor combination, because it means that the server must understand all the things I am allowed to do, even if it doesn't implement them. And really, "permit foo" is not a constraint at all; it's the reverse of a constraint. I recommend _both_ inverting the sense of the "permit-*" items _and_ allowing for non-critical extensions, which are often essential for extending a protocol in a meaningful way. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 14:04:00 2010 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 78CA63A680F for ; Tue, 16 Mar 2010 14:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 Ql312pzYRPFf for ; Tue, 16 Mar 2010 14:03: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 DF77E3A67C0 for ; Tue, 16 Mar 2010 14:03:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 229E163B135; Tue, 16 Mar 2010 21:03:47 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 D730563B130 for ; Tue, 16 Mar 2010 21:03:45 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 0799AC4AD5; Wed, 17 Mar 2010 07:45:30 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id DE11EC4AAB; Wed, 17 Mar 2010 07:45:24 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 64D555316F; Wed, 17 Mar 2010 07:45:24 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 63F075278B; Wed, 17 Mar 2010 07:45:24 +1100 (EST) Date: Wed, 17 Mar 2010 07:45:24 +1100 (EST) From: Damien Miller To: "denis bider \\(Bitvise\\)" cc: Nicolas Williams , ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: Message-ID: References: <20100316185552.GP14993@Sun.COM> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 16 Mar 2010, denis bider \(Bitvise\) wrote: > I second Nicolas's concern. Your spec doesn't even mention revocation. > How is revocation handled? Are the keys expected to be certified only > for a very short term? > > If certification is expected to be for only a very short term, are you > putting an infrastructure in place that allows a client to obtain a > fresh certificate before it connects? > > If you are putting such infrastructure in place, do you have a spec for > how the client obtains the fresh certificate? > > Otherwise, if you are planning for these certificates to be long-term, > what is your solution for revocation? For OpenSSH, revocation is implemented as a simple list of banned keys. Since keys are the entity that is revoked and not certificates, and because there are no wire-side changes require for revocation, I don't really see it as part of this certificate specification. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 14:07:11 2010 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 1E7EF3A6A79 for ; Tue, 16 Mar 2010 14:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.61 X-Spam-Level: X-Spam-Status: No, score=-8.61 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_50=0.001, 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 25UC+uPCgHTT for ; Tue, 16 Mar 2010 14:07: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 E79D43A6A2C for ; Tue, 16 Mar 2010 14:07:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 83B4763B13B; Tue, 16 Mar 2010 21:07:11 +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 7FAF763B104 for ; Tue, 16 Mar 2010 21:07:08 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA20561; Tue, 16 Mar 2010 17:07:07 -0400 (EDT) From: der Mouse Message-Id: <201003162107.RAA20561@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, 16 Mar 2010 16:54:53 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> In particular, we are not comfortable with the complexity >> (syntactically or sematically) of X.509. > That's unfortunate, because it's what the rest of the world already > has as its infrastructure. This is clearly some unusual definition of "world" I'm not familiar with. I'm familiar with three sites' setups. One of them uses X.509 for nothing at all. Another does likewise as far as I can tell, but I'm not quite familiar enough with it to be sure there isn't something lurking in a corner I haven't seen. A third uses X.509 certificate format, but with a private root CA they've set up for their own purposes; I don't know enough about X.509 to know whether this means they don't conform to it or not. (If the software they're using it with supported something less onerous, they very probably would have used that instead.) In none of those three cases is X.509 "what they have as their infrasturcture". > By not supporting it, you force people to choose between supporting > your odd, proprietary, unproven certificate format or not getting to > use certificates at all. Or, of course, using some other ssh implementation. > Guess which one anyone with more than 5 machines is going to choose? Speaking as someone with more than 5 machines, I have even less interest in X.509 than I do in this new certificate scheme. X.509 is about what you'd expect from design-by-committee: over-complicated, difficult to use, and blithely oblivious to the ways in which its underlying assumptions are at odds with day-to-day reality. > OpenSSH would be a lot more useful if it supported the same > authentication mechanisms as the rest of the world. Again this odd value of "rest of the world". X.509 support might be nice to have (though I'm certainly not going to bother writing the code). But I'm glad to see experiments with alternatives as well; monocultures are bad things. /~\ 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 Mar 16 14:12:58 2010 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 8306A3A6B5C for ; Tue, 16 Mar 2010 14:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 gWuw8ykWSlKF for ; Tue, 16 Mar 2010 14:12:56 -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 BA5533A6B48 for ; Tue, 16 Mar 2010 14:12:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A84D63B154; Tue, 16 Mar 2010 21:12:48 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet14.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id ADEB163B151 for ; Tue, 16 Mar 2010 21:12:46 +0000 (UTC) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rcsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o2GLCifX023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Mar 2010 21:12:46 GMT Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2GLCLGb031948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Mar 2010 21:12:22 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2GJi54t023244; Tue, 16 Mar 2010 21:12:20 GMT Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 90793511268773936; Tue, 16 Mar 2010 14:12:16 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 14:12:16 -0700 Date: Tue, 16 Mar 2010 16:12:11 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100316211211.GD14993@Sun.COM> References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4B9FF434.0237,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Mar 16, 2010 at 03:42:53PM -0400, Jeffrey Hutzelman wrote: > --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller > wrote: > >OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > >user and host keys. These were designed to reuse SSH wire-encoding and > >signature primitives to minimise the additional attack surface exposed > >pre-auth. In particular, we are not comfortable with the complexity > >(syntactically or sematically) of X.509. > > That's unfortunate, because it's what the rest of the world already > has as its infrastructure. By not supporting it, you force people > to choose between supporting your odd, proprietary, unproven > certificate format or not getting to use certificates at all. Guess > which one anyone with more than 5 machines is going to choose? If this is billed as a simple PKI for small environments then I think that's fine. But if anyone tries to grow a deployment of this PKI much larger then they'll either need to switch to PKIX, to Kerberos, or you'll need to grow your PKI protocol to cover their needs. Growing this PKI protocol puts it in direct competition with PKIX. The rest of us will need some compelling rationales for implementing a competitor to PKIX, and those are going to be hard to come by because of the very large deployed base of PKIX. > OpenSSH would be a lot more useful if it supported the same > authentication mechanisms as the rest of the world. I agree. We really should finish the SSHv2-with-x.509 spec, or else finish PKU2U and deploy that. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 14:14:33 2010 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 401FD3A6827 for ; Tue, 16 Mar 2010 14:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 4QacGee0FU3D for ; Tue, 16 Mar 2010 14:14:32 -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 897C93A6AD0 for ; Tue, 16 Mar 2010 14:14:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9744663B155; Tue, 16 Mar 2010 21:14:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from acsinet14.oracle.com (acsinet14.oracle.com [141.146.126.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "acsinet14.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id C6C0A63B151 for ; Tue, 16 Mar 2010 21:14:26 +0000 (UTC) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by acsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o2GJkANO016997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Mar 2010 19:46:11 GMT Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2GJjmch002092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Mar 2010 19:45:50 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2GJjlHu026935; Tue, 16 Mar 2010 19:45:47 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 85698221268768731; Tue, 16 Mar 2010 12:45:31 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 12:45:30 -0700 Date: Tue, 16 Mar 2010 14:45:26 -0500 From: Nicolas Williams To: Damien Miller Cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100316194525.GW14993@Sun.COM> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4B9FDFEC.00B8,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list How will extensions to this PKI cert format be handled? I see nothing about criticality... I understand the aversion to PKIX, which probably derives from an aversion to x.500-style naming, ASN.1 and BER/DER/CER. But there are more lessons to be learned from PKIX than "x.500 sucks" and "BER sucks". I also understand the intention of having a simple cert format just for use with SSHv2. But SSHv2 doesn't exist in isolation. People use it in environments where they use Kerberos, so we've added extensions to allow the use of GSS-API mechanisms and, through that, Kerberos. Similarly for PKIX. If this cert format becomes popular then people will want to use it elsewhere for the simple reason that having more than one credentials/authentication infrastructure sucks. To me this means that we have to ask whether this is desirable right now. If it becomes popular then, of course, it sure will be desirable (and to be sure, I think the OpenSSH team certainly has the ability to make this protocol popular). Which means that we'd better get some aspects of this Right right now; at minimum these issues have to be handled correctly from day 1: - revocation (PKIX lesson: CRLs _suck_) - extensibility (how to add critical and non-critical cert elements) - principal naming (there's more than just 'hostnames' and 'usernames') - federation / CA naming / PKI hierarchies, including mapping to the DNS (you might rely entirely on DNSSEC for hierarchy, that'd be a fine solution) Implementation-wise I urge to to make this as much library-like as possible, so that eventually you can make a trivial GSS-API mechanism out of it. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 15:43:58 2010 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 6DDAD3A6AAD for ; Tue, 16 Mar 2010 15:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPzbnXc+zWmf for ; Tue, 16 Mar 2010 15:43:57 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 9C8BE3A6975 for ; Tue, 16 Mar 2010 15:43:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2E61063B1CB; Tue, 16 Mar 2010 22:43:56 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from wilbur.25thandClement.com (wilbur.25thandclement.com [68.68.99.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.25thandClement.com", Issuer "25thandClement.com" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id A17F863B125 for ; Tue, 16 Mar 2010 22:43:54 +0000 (UTC) Received: from wilbur.25thandClement.com (william@localhost.25thandClement.com [127.0.0.1]) by wilbur.25thandClement.com (8.14.3/8.14.1) with ESMTP id o2GLEjut009362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Mar 2010 14:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=25thandClement.com; s=jan2009; t=1268774085; bh=gnJY8lQD37YCi8rUVbcGl3jom24fl40opd6NF41CfNE=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=NuvG5YFGrTKzphUQE5qH+yFZAB0oom2CH5WRR2QaG8ysmhm0kx5Q9fWtViOAJkl9y Gu1zGizx/iIELo+rq/1IGOsRxoRJCJ60VCcdGEpvQ6P4V63NAsony/WvCL013WpiRg tj8f1JtxyACqEBRKQQ4Og0b9neo9ZsI8Tt3UZW1A= Received: (from william@localhost) by wilbur.25thandClement.com (8.14.3/8.14.3/Submit) id o2GLEjEY016940 for ietf-ssh@NetBSD.org; Tue, 16 Mar 2010 14:14:45 -0700 (PDT) Date: Tue, 16 Mar 2010 14:14:45 -0700 From: William Ahern To: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100316211445.GA25418@wilbur.25thandClement.com> References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Mar 16, 2010 at 03:42:53PM -0400, Jeffrey Hutzelman wrote: > --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller > wrote: > > >OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > >user and host keys. These were designed to reuse SSH wire-encoding and > >signature primitives to minimise the additional attack surface exposed > >pre-auth. In particular, we are not comfortable with the complexity > >(syntactically or sematically) of X.509. > > That's unfortunate, because it's what the rest of the world already has as > its infrastructure. By not supporting it, you force people to choose > between supporting your odd, proprietary, unproven certificate format or > not getting to use certificates at all. Guess which one anyone with more > than 5 machines is going to choose? > > OpenSSH would be a lot more useful if it supported the same authentication > mechanisms as the rest of the world. IMO the complexity of ASN.1 is overstated. But the fact of the matter is that there aren't any decent--simple and small--ASN.1 C libraries (or Perl or any other language for that matter). There's one very good free compiler, asn1c: http://lionet.info/asn1c/ I've used it extensively for internal cluster messaging. asn1c supports asynchronous I/O as the parsers it generates are restartable. But it's also perhaps too heavy weight. A more useful ASN.1 compiler, IMO, would support member arrays rather than only pointers, and generate much less code for common types. That said, OpenSSH already had time-tested building blocks; specifically the SSH protocol and implemention. "[T]he serialised wire encoding of [the] certificates is also used for storing them on disk." Of course ASN.1 would be "too complex" for OpenSSH when minimal code needs to be written when re-using the existing string parsers and other infrastructure. ASN.1 will continue to sit on the sidelines in the FOSS world as long as there's no appealing library and/or compiler to make it the easy choice for people. Indeed, using ASN.1 in a new proprietary product or protocol is a very good way to keep FOSS competition at bay. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 15:55:38 2010 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 C452D3A6B5A for ; Tue, 16 Mar 2010 15:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.640, 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 b3wZvYcweXOu for ; Tue, 16 Mar 2010 15:55: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 7DFC73A6AD8 for ; Tue, 16 Mar 2010 15:53:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 63C2463B1CB; Tue, 16 Mar 2010 22:53:03 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 1A7EE63B125 for ; Tue, 16 Mar 2010 22:53:00 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 3EEA2C4AD5; Wed, 17 Mar 2010 09:52:10 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id B558AC4AF8; Wed, 17 Mar 2010 09:52:04 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 69A345278B; Wed, 17 Mar 2010 09:52:04 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 6882B5278A; Wed, 17 Mar 2010 09:52:04 +1100 (EST) Date: Wed, 17 Mar 2010 09:52:04 +1100 (EST) From: Damien Miller To: Jeffrey Hutzelman cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> Message-ID: References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote: > --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller > wrote: > > > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > > user and host keys. These were designed to reuse SSH wire-encoding and > > signature primitives to minimise the additional attack surface exposed > > pre-auth. In particular, we are not comfortable with the complexity > > (syntactically or sematically) of X.509. > > That's unfortunate, because it's what the rest of the world already has as its > infrastructure. By not supporting it, you force people to choose between > supporting your odd, proprietary, unproven certificate format or not getting > to use certificates at all. Guess which one anyone with more than 5 machines > is going to choose? > > OpenSSH would be a lot more useful if it supported the same authentication > mechanisms as the rest of the world. Well, unfortunately we consider the additional complexity and attack surface added by X.509 to be too great. That being said, there are well-maintained 3rd party patches to OpenSSH that support X.509 certificates if users have a need that isn't supported by this mechanism. > > signature key contains the CA key used to sign the certificate. > > The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained" > > certificates, where the signature key type is a certificate type itself > > are NOT supported. Note that it is possible for a RSA certificate key to > > be signed by a DSS CA key and vice-versa. > > This seems like a serious shortcoming. Practically no one uses single-level > certificate heirarchies any more; there's nearly always at least one > intermediate CA for operational and security reasons. Taking out this feature > makes the system less secure. I disagree with this too. This certificate format isn't saddled with X.509's one-PKI-to-bind-them mentality and doesn't have to be singly-rooted. OpenSSH supports simultaneous trust of multiple CA keys, so this deals with CA key revocation and rollover differently. > > The name field identifies the constraint and the data field encodes > > constraint-specific information (see below). All constraints are > > "critical", if an implementation does not recognise a constraint > > then the validating party should refuse to accept the certificate. > > ... > > permit-X11-forwarding empty Flag indicating that X11 forwarding > > should be permitted. X11 forwarding > > will be refused if this constraint > > is absent. > > > This is a poor combination, because it means that the server must understand > all the things I am allowed to do, even if it doesn't implement them. And > really, "permit foo" is not a constraint at all; it's the reverse of a > constraint. > > I recommend _both_ inverting the sense of the "permit-*" items _and_ allowing > for non-critical extensions, which are often essential for extending a > protocol in a meaningful way. I agree that the term "constraint" may be something of a misnomer, but disagree that the sense of the extension should be flipped. The intention here is that new protocol features should not be automatically granted to old certificates. If the "constraints" _disable_ protocol features then they will inherit whatever ambient permissions may be added in the future. wrt non-critical extensions. This is a possibility, via the "reserved" field in the future if they are really necessary. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 16:11:47 2010 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 235613A67E4 for ; Tue, 16 Mar 2010 16:11:47 -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 wKL0RaomEFh6 for ; Tue, 16 Mar 2010 16:11:46 -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 A371C3A6813 for ; Tue, 16 Mar 2010 16:11:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4DA2963B144; Tue, 16 Mar 2010 23:11:22 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 101F563B137 for ; Tue, 16 Mar 2010 23:11:16 +0000 (UTC) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2GNB7lj020270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 19:11:07 -0400 (EDT) Date: Tue, 16 Mar 2010 19:11:07 -0400 From: Jeffrey Hutzelman To: Damien Miller cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: OpenSSH certified keys Message-ID: <1DC94A5092487CC7E650DB46@lysithea.fac.cs.cmu.edu> In-Reply-To: References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, March 17, 2010 09:52:04 AM +1100 Damien Miller wrote: >> OpenSSH would be a lot more useful if it supported the same >> authentication mechanisms as the rest of the world. > > Well, unfortunately we consider the additional complexity and attack > surface added by X.509 to be too great. That being said, there are > well-maintained 3rd party patches to OpenSSH that support X.509 > certificates if users have a need that isn't supported by this mechanism. As I said, that's unfortunate. >> This seems like a serious shortcoming. Practically no one uses >> single-level certificate heirarchies any more; there's nearly always at >> least one intermediate CA for operational and security reasons. Taking >> out this feature makes the system less secure. > > I disagree with this too. This certificate format isn't saddled with > X.509's one-PKI-to-bind-them mentality and doesn't have to be > singly-rooted. OpenSSH supports simultaneous trust of multiple CA keys, > so this deals with CA key revocation and rollover differently. I see no such mentality. The several most widely-deployed X.509 implementations all support multiple trust anchors, and both X.509 and PKIX contemplate the possibility of such. However, that's not a sufficient answer to scalability issues that multi-level PKI's solve. It also doesn't allow for the sorts of cutouts that allow one to sign certificates on a regular basis while keeping the secret key for the widely-distributed trust anchor offline and under lock and key, which is important given the operational impact of having to revoke that key. BTW, saying you revoke keys rather than certificates doesn't really do much. Who is authorized to revoke a key? How is that information distributed. A server configuration option that must be manually maintained on each SSH server is not really a scalable solution to this problem, especially when the majority of servers are not operated by the same person as the CA. > I agree that the term "constraint" may be something of a misnomer, but > disagree that the sense of the extension should be flipped. The intention > here is that new protocol features should not be automatically granted to > old certificates. That's fine, but should be up to the CA. For example, one might have a constraint that prohibits use of (some class of) protocol features other than ones explicitly listed. In your model, not only is there no way to issue a certificate which can be used with any protocol features including new ones, there is also no way to issue a certificate which allows use of a new protocol feature but can be also used with servers that do not yet support that feature. That means I need a separate certificate for every permutation of features supported by the servers I use, which again is not scalable. If the "constraints" _disable_ protocol features then > they will inherit whatever ambient permissions may be added in the future. > > wrt non-critical extensions. This is a possibility, via the "reserved" > field in the future if they are really necessary. But you haven't defined how the reserved field will work, or what it MUST contain in the current protocol. So not only is it impossible for anyone to define such an extension without "taking over" this field (and you've defined no means of coordination for that); you've actually made it impossible to use the field at all, because no one can predict what existing servers will do with it or what it might contain in existing certificates. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 16:16:35 2010 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 BE1193A68E4 for ; Tue, 16 Mar 2010 16:16:35 -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 SOJabOmPej48 for ; Tue, 16 Mar 2010 16:16: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 D5FEB3A6824 for ; Tue, 16 Mar 2010 16:16:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4DF7B63B208; Tue, 16 Mar 2010 23:16:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 101F663B1EA for ; Tue, 16 Mar 2010 23:16:32 +0000 (UTC) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2GNGJBI020342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 19:16:19 -0400 (EDT) Date: Tue, 16 Mar 2010 19:16:19 -0400 From: Jeffrey Hutzelman To: William Ahern , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: OpenSSH certified keys Message-ID: <8D0F1BFD554DF7C0BFCBCB60@lysithea.fac.cs.cmu.edu> In-Reply-To: <20100316211445.GA25418@wilbur.25thandClement.com> References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> <20100316211445.GA25418@wilbur.25thandClement.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.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Tuesday, March 16, 2010 02:14:45 PM -0700 William Ahern wrote: > ASN.1 will continue to sit on the sidelines in the FOSS world as long as > there's no appealing library and/or compiler to make it the easy choice > for people. Indeed, using ASN.1 in a new proprietary product or protocol > is a very good way to keep FOSS competition at bay. You mean, except for widely-deployed protocols like PKIX, Kerberos, SNMP, and LDAP, all of which have multiple open-source implementations. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 16:22:54 2010 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 3CD4F3A690E for ; Tue, 16 Mar 2010 16:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, 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 7deN3S4Xf1DG for ; Tue, 16 Mar 2010 16:22:51 -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 182943A696B for ; Tue, 16 Mar 2010 16:22:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1126363B1FC; Tue, 16 Mar 2010 23:22:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 BCD3F63B126 for ; Tue, 16 Mar 2010 23:22:49 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 81317C4AD5; Wed, 17 Mar 2010 10:22:47 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id A37CAC4AAB; Wed, 17 Mar 2010 10:22:42 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 4E5A45278B; Wed, 17 Mar 2010 10:22:42 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 4BE755278A; Wed, 17 Mar 2010 10:22:42 +1100 (EST) Date: Wed, 17 Mar 2010 10:22:42 +1100 (EST) From: Damien Miller To: Roumen Petrov cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: <4BA00F80.3090009@roumenpetrov.info> Message-ID: References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> <4BA00F80.3090009@roumenpetrov.info> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 17 Mar 2010, Roumen Petrov wrote: > I think that one of issue to previous drafts (O. Saarenmaa and J. > Galbraith) as Damien point to this list was that ssh server has to > parse asn.1. At present, the SSH server doesn't have to parse ASN.1. The ssh-rsa signature format does *use* ASN.1 encoding, but it is enough of a canonical representation that a general parser is not needed. Avoiding the use of ASN.1 here has saved OpenSSH from a few bugs in OpenSSL's ASN.1 routines over the years. BTW, that several other ASN.1 implementations have suffered from multiple bugs over the years is (to me at least) a good signal that the format itself is problematic. See http://anoncvs.mindrot.org/index.cgi/openssh/ssh-rsa.c?revision=HEAD for more details. > If I understand Damien most acceptable is solution is if ssh could > read without to process(parse) certificate(s) data and to pass to > external system for further processing. Damien ? I don't think there is much getting away from the fact that there is a lot of complexity in the pre-auth path when adding X.509. While delegating verification and authorisation decisions to a sandboxed agent outside the SSH server is an improvement, the complexity is still in the critical path. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 16:39:57 2010 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 111A23A68BD for ; Tue, 16 Mar 2010 16:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, SARE_LWSHORTT=1.24] 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 ZeUToOEFlJ-G for ; Tue, 16 Mar 2010 16:39:56 -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 185AB3A68A3 for ; Tue, 16 Mar 2010 16:39:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 98CB363B163; Tue, 16 Mar 2010 23:39:59 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 1ECA363B126 for ; Tue, 16 Mar 2010 23:39:57 +0000 (UTC) Received: from element ([205.217.224.99]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 16 Mar 2010 19:40:04 -0400 Message-ID: <6DC7CD40E2FA4226B671A6BF7F17C450@element> From: "denis bider \(Bitvise\)" To: "Damien Miller" Cc: References: <20100316185552.GP14993@Sun.COM> In-Reply-To: Subject: Re: OpenSSH certified keys Date: Tue, 16 Mar 2010 19:40:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien, > For OpenSSH, revocation is implemented as a simple list > of banned keys. Since keys are the entity that is revoked > and not certificates, and because there are no wire-side > changes require for revocation, I don't really see it as > part of this certificate specification. does this list of banned keys need to be manually deployed to each server, or does OpenSSH support a protocol for retrieving this list remotely? If the list of banned keys must be manually deployed, then this sounds worse than CRL. In this case, you're introducing a scheme which allows new keys to be added centrally, but requires manually updating the configuration of each server when keys are revoked. On the other hand, if OpenSSH is capable of retrieving the list of banned keys periodically, then the protocol for doing so is of interest to other implementors as well. If one intends to interoperate with the OpenSSH certificate format, then one should certainly support retrieving the list of banned keys as well. denis ----- Original Message ----- From: "Damien Miller" To: "denis bider \(Bitvise\)" Cc: "Nicolas Williams" ; Sent: Tuesday, March 16, 2010 16:45 Subject: Re: OpenSSH certified keys On Tue, 16 Mar 2010, denis bider \(Bitvise\) wrote: > I second Nicolas's concern. Your spec doesn't even mention revocation. > How is revocation handled? Are the keys expected to be certified only > for a very short term? > > If certification is expected to be for only a very short term, are you > putting an infrastructure in place that allows a client to obtain a > fresh certificate before it connects? > > If you are putting such infrastructure in place, do you have a spec > for > how the client obtains the fresh certificate? > > Otherwise, if you are planning for these certificates to be long-term, > what is your solution for revocation? For OpenSSH, revocation is implemented as a simple list of banned keys. Since keys are the entity that is revoked and not certificates, and because there are no wire-side changes require for revocation, I don't really see it as part of this certificate specification. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 16:54:50 2010 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 DB5343A6A2A for ; Tue, 16 Mar 2010 16:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 Jtao32MFpq4y for ; Tue, 16 Mar 2010 16:54:49 -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 441E93A69EA for ; Tue, 16 Mar 2010 16:54:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4771263B18D; Tue, 16 Mar 2010 23:54:47 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 04A3363B12F for ; Tue, 16 Mar 2010 23:54:44 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 9CE20C4AD5; Wed, 17 Mar 2010 10:54:39 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id E052EC4AAB; Wed, 17 Mar 2010 10:54:33 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 8FEF55278B; Wed, 17 Mar 2010 10:54:33 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 8D3965278A; Wed, 17 Mar 2010 10:54:33 +1100 (EST) Date: Wed, 17 Mar 2010 10:54:33 +1100 (EST) From: Damien Miller To: Jeffrey Hutzelman cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: <1DC94A5092487CC7E650DB46@lysithea.fac.cs.cmu.edu> Message-ID: References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> <1DC94A5092487CC7E650DB46@lysithea.fac.cs.cmu.edu> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote: > --On Wednesday, March 17, 2010 09:52:04 AM +1100 Damien Miller > wrote: > > > > This seems like a serious shortcoming. Practically no one uses > > > single-level certificate heirarchies any more; there's nearly > > > always at least one intermediate CA for operational and security > > > reasons. Taking out this feature makes the system less secure. > > > > I disagree with this too. This certificate format isn't saddled > > with X.509's one-PKI-to-bind-them mentality and doesn't have to be > > singly-rooted. OpenSSH supports simultaneous trust of multiple CA > > keys, so this deals with CA key revocation and rollover differently. > > I see no such mentality. The several most widely-deployed X.509 > implementations all support multiple trust anchors, and both X.509 > and PKIX contemplate the possibility of such. However, that's not a > sufficient answer to scalability issues that multi-level PKI's solve. > It also doesn't allow for the sorts of cutouts that allow one to sign > certificates on a regular basis while keeping the secret key for the > widely-distributed trust anchor offline and under lock and key, which > is important given the operational impact of having to revoke that > key. A similar operational effect could be achieved by having additional trusted CA keys established ahead of time and securely placed in reserve for the case where a primary CA key is compromised. Next? In case you are wondering, recursive verification is not included for reasons of conceptual and implementation simplicity. > BTW, saying you revoke keys rather than certificates doesn't really > do much. Who is authorized to revoke a key? How is that information > distributed. A server configuration option that must be manually > maintained on each SSH server is not really a scalable solution to > this problem, especially when the majority of servers are not operated > by the same person as the CA. I don't really see the mechanism of key revocation as part of the certificate _format_. Just because X.509 includes it there isn't a strong reason that others need to do so. In answer to your question, the current OpenSSH implementation supports a text file of revoked keys distributed out of band. This isn't scalable, but it isn't the only possibility; it wouldn't be hard to define an online method of testing key revocation (a la OCSP), perhaps via a new SSH subsystem. A defined subsystem for enrolling keys would be nice, but that is outside the scope of the certificate format description too. > > I agree that the term "constraint" may be something of a misnomer, > > but disagree that the sense of the extension should be flipped. > > The intention here is that new protocol features should not be > > automatically granted to old certificates. > > That's fine, but should be up to the CA. For example, one might > have a constraint that prohibits use of (some class of) protocol > features other than ones explicitly listed. In your model, not only > is there no way to issue a certificate which can be used with any > protocol features including new ones, there is also no way to issue > a certificate which allows use of a new protocol feature but can be > also used with servers that do not yet support that feature. That > means I need a separate certificate for every permutation of features > supported by the servers I use, which again is not scalable. That is a fair point and it is potentially worth reconsidering the criticality of certificate extensions because of it. I think that in the presence of non-critical extensions though, the sense of the extensions is more important; if a non-critical extension that disables some protocol feature is skipped by an implementation that does not understand it (but does implement the protocol feature), then there are more security consequences than the converse. > If the "constraints" _disable_ protocol features then > they will > inherit whatever ambient permissions may be added in the future. > > > wrt non-critical extensions. This is a possibility, via the "reserved" > > field in the future if they are really necessary. > > But you haven't defined how the reserved field will work, or what it > MUST contain in the current protocol. So not only is it impossible > for anyone to define such an extension without "taking over" this > field (and you've defined no means of coordination for that); you've > actually made it impossible to use the field at all, because no one > can predict what existing servers will do with it or what it might > contain in existing certificates. The document I sent is not set in stone (clearly; it was sent for feedback) and there is only one server that implements it, which happens to ignore this field's contents. So using it as an extensibility mechanism is a simple matter of clarifying its intent in the specification. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 16:58:19 2010 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 C55A33A697E for ; Tue, 16 Mar 2010 16:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 eg3dw+hSQV0d for ; Tue, 16 Mar 2010 16:58: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 2B72D3A6818 for ; Tue, 16 Mar 2010 16:58:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 575C563B12F; Tue, 16 Mar 2010 23:58:21 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (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 0F75163B1FD for ; Tue, 16 Mar 2010 23:58:19 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 28A17C4AD5; Wed, 17 Mar 2010 10:58:18 +1100 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 7F785C4AAB; Wed, 17 Mar 2010 10:58:13 +1100 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 331FC5278B; Wed, 17 Mar 2010 10:58:13 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 30B7B5278A; Wed, 17 Mar 2010 10:58:13 +1100 (EST) Date: Wed, 17 Mar 2010 10:58:13 +1100 (EST) From: Damien Miller To: "denis bider \\(Bitvise\\)" cc: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys In-Reply-To: <6DC7CD40E2FA4226B671A6BF7F17C450@element> Message-ID: References: <20100316185552.GP14993@Sun.COM> <6DC7CD40E2FA4226B671A6BF7F17C450@element> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 16 Mar 2010, denis bider \(Bitvise\) wrote: > Damien, > > > For OpenSSH, revocation is implemented as a simple list > > of banned keys. Since keys are the entity that is revoked > > and not certificates, and because there are no wire-side > > changes require for revocation, I don't really see it as > > part of this certificate specification. > > does this list of banned keys need to be manually deployed to each > server, or does OpenSSH support a protocol for retrieving this list > remotely? > > If the list of banned keys must be manually deployed, then this sounds > worse than CRL. In this case, you're introducing a scheme which allows > new keys to be added centrally, but requires manually updating the > configuration of each server when keys are revoked. > > On the other hand, if OpenSSH is capable of retrieving the list of > banned keys periodically, then the protocol for doing so is of interest > to other implementors as well. If one intends to interoperate with the > OpenSSH certificate format, then one should certainly support retrieving > the list of banned keys as well. The list of revoked keys is just a file on disk and OpenSSH implements no special means to update it (so far). We could define some distribution service or an online protocol to lookup key revocation status, possibly as a SSH subsystem. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 17:24:27 2010 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 37B7E3A68DD for ; Tue, 16 Mar 2010 17:24:27 -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 3RiXTjrdMCNl for ; Tue, 16 Mar 2010 17:24:25 -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 AB9183A6A70 for ; Tue, 16 Mar 2010 17:24:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5AF7963B1FA; Wed, 17 Mar 2010 00:24:22 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from filter.host.bg (filter.host.bg [87.120.40.9]) by mail.netbsd.org (Postfix) with ESMTP id 0C5E563B1EE for ; Wed, 17 Mar 2010 00:24:20 +0000 (UTC) Received: from mail.host.bg (mail.host.bg [87.120.40.3]) by filter.host.bg (Postfix) with SMTP id 96A8EBE3CA; Wed, 17 Mar 2010 01:09:10 +0200 (EET) Received: from [85.130.48.100] (85-130-48-100.1699525.ddns.cablebg.net [85.130.48.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.host.bg (Postfix) with ESMTP id A34BFD25D5AA7; Wed, 17 Mar 2010 01:15:44 +0200 (EET) Message-ID: <4BA00F80.3090009@roumenpetrov.info> Date: Wed, 17 Mar 2010 01:08:48 +0200 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100223 SeaMonkey/2.0.3 MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> In-Reply-To: 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 Hi Jeffrey, Damien Miller wrote: > On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote: >> --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller >> wrote: >> >>> OpenSSH 5.4p1 introduced a novel, lightweight certificate format for >>> user and host keys. [SNIP] >> >> That's unfortunate, because it's what the rest of the world already has as its >> infrastructure. By not supporting it, you force people to choose between >> supporting your odd, proprietary, unproven certificate format or not getting >> to use certificates at all. Guess which one anyone with more than 5 machines >> is going to choose? >> >> OpenSSH would be a lot more useful if it supported the same authentication >> mechanisms as the rest of the world. > > Well, unfortunately we consider the additional complexity and attack surface > added by X.509 to be too great. That being said, there are well-maintained > 3rd party patches to OpenSSH that support X.509 certificates if users have > a need that isn't supported by this mechanism. I think that one of issue to previous drafts (O. Saarenmaa and J. Galbraith) as Damien point to this list was that ssh server has to parse asn.1. If I understand Damien most acceptable is solution is if ssh could read without to process(parse) certificate(s) data and to pass to external system for further processing. Damien ? The recent draft (K. Igoe and D. Stebile http://tools.ietf.org/html/draft-igoe-secsh-x509v3-01 ) didn't resolve this issue. [SNIP] Roumen From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 17:29:54 2010 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 22B913A69AA for ; Tue, 16 Mar 2010 17:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_50=0.001] 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 1c7fdYPuwfos for ; Tue, 16 Mar 2010 17:29: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 51BC53A6975 for ; Tue, 16 Mar 2010 17:29:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2A3CF63B1FD; Wed, 17 Mar 2010 00:29:49 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from wilbur.25thandClement.com (wilbur.25thandclement.com [68.68.99.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.25thandClement.com", Issuer "25thandClement.com" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id BF3BD63B1EE for ; Wed, 17 Mar 2010 00:29:47 +0000 (UTC) Received: from wilbur.25thandClement.com (william@localhost.25thandClement.com [127.0.0.1]) by wilbur.25thandClement.com (8.14.3/8.14.1) with ESMTP id o2H0TlpE023252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Mar 2010 17:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=25thandClement.com; s=jan2009; t=1268785787; bh=CJTvaqlxxDMRILZrQ/M9d8xml9QlTnKkXBDIazpKSeY=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=LDCMVPw5uNtZOWolpGVJXxvGpi/I5At9l8P3g9HnmaxgpfYnvGMXOu+CABFnSAG6f aEnWe2SWpXjh1Ops7vzeujM/buVpW08AuUpKoKv/dtDC8OMtdeoBgqYpoF0dbPCii0 bSlf9KhIHw982Xtv59oE+FhC5MIzG1AfYgrf+aF4= Received: (from william@localhost) by wilbur.25thandClement.com (8.14.3/8.14.3/Submit) id o2H0TlAI030251 for ietf-ssh@NetBSD.org; Tue, 16 Mar 2010 17:29:47 -0700 (PDT) Date: Tue, 16 Mar 2010 17:29:47 -0700 From: William Ahern To: ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100317002947.GA11660@wilbur.25thandClement.com> References: <4BCB9A7CFD1EB9BED499815D@minbar.fac.cs.cmu.edu> <20100316211445.GA25418@wilbur.25thandClement.com> <8D0F1BFD554DF7C0BFCBCB60@lysithea.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D0F1BFD554DF7C0BFCBCB60@lysithea.fac.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Mar 16, 2010 at 07:16:19PM -0400, Jeffrey Hutzelman wrote: > --On Tuesday, March 16, 2010 02:14:45 PM -0700 William Ahern > wrote: > > >ASN.1 will continue to sit on the sidelines in the FOSS world as long as > >there's no appealing library and/or compiler to make it the easy choice > >for people. Indeed, using ASN.1 in a new proprietary product or protocol > >is a very good way to keep FOSS competition at bay. > > You mean, except for widely-deployed protocols like PKIX, Kerberos, SNMP, > and LDAP, all of which have multiple open-source implementations. All of those protocols were created in the 1990's. Each open source implementation wrote their own implementation of the relevant ASN.1 codecs, largely only suited to their particular task. And they did so because the particular protocol was already ubiquitous. Only SNMP has a significant number of open source implementations, and SNMP is simplified. AFAIK, there are no recent protocols that have used ASN.1. In fact, most use XML largely because of the ubiquity of Clark's expat and, subsequently, GNOME's libxml. (Hype obviously played a part, but those susceptible to hype aren't as well represented in the class of those able to write decent infrastructure software.) The only library that OpenSSH currently depends on is OpenSSL, and their implemention is horrible by their own admission (and manifestly untrustworthy). OpenSSH is a conservative project, existing implementations aren't suitable (and they'd have to be exceptional, I think, for OpenSSH to accept a new dependency), and the project is understandably reticent to write a huge new chunk of code. If ASN.1 is to garner mindshare (and respect), it minimally needs something like expat to reduce costs. As things stand, unless you work in telecom there's no future for ASN.1. ASN.1 isn't on anyone's radar. Look at phenomena like Google's Protocol Buffers. That and similar projects provide nothing more (and usually not much less, either) than ASN.1. Why go thru the bother of writing a new specification _and_ new code? It's not logical to my mind, but that's the way things are. ASN.1 isn't as simple as line-oriented protocols (which are in abundance), nor are there any best-of-breed implementations. Therefore you see a flourishing of ad hoc designs. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 16 18:20:42 2010 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 172DF3A6810 for ; Tue, 16 Mar 2010 18:20:42 -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 tYuQzWdDQpjc for ; Tue, 16 Mar 2010 18:20:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B63BA3A67FB for ; Tue, 16 Mar 2010 18:20:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E883363B1FC; Wed, 17 Mar 2010 01:20:34 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from shannon.crazycode.ca (shannon.crazycode.ca [173.203.208.70]) by mail.netbsd.org (Postfix) with ESMTP id 605EA63B20C for ; Wed, 17 Mar 2010 01:20:28 +0000 (UTC) Received: from [131.181.103.233] (unknown [131.181.103.233]) (Authenticated sender: dstebila@crazycode.ca) by shannon.crazycode.ca (Postfix) with ESMTPSA id 153E4980A2; Wed, 17 Mar 2010 00:04:51 +0000 (UTC) Subject: Re: OpenSSH certified keys Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Douglas Stebila In-Reply-To: Date: Wed, 17 Mar 2010 10:04:50 +1000 Cc: ietf-ssh@netbsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3466E381-CECF-4B00-B29C-141C7CCFDC63@stebila.ca> References: To: Damien Miller X-Mailer: Apple Mail (2.1077) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list The OpenSSL certkeys protocol has some similarities to our present = X.509-in-SSH proposal, but also differs in at least three major ways; = there are some lessons for each to learn from the other, but there are = also some fundamental incompatibilities. User/host identifiers: Our draft leaves the mapping between certificates = and usernames / hostnames up to the implementation and system = administrators. Perhaps we should revisit the issue of mapping = hostnames, but I believe that having the CA map certificates to = usernames is inappropriate. The same user (with the same certificate) = may intend to use that certificate with multiple servers, and have = different usernames on each server. For example, on their primary work = computer the user may have the username "admin", and on their = departmental web server have the username "bsmith"; but the = administrator of the departmental web server may not wish to allow that = user to access the web server as "admin". Revocation: At the request of members of this list, our draft -01 = incorporated a mechanism for a party to relay certificate status / = revocation information (specifically, OCSP responses) along with any = certificates delivered during the exchange. I was convinced by = arguments made by members of this list that checking revocation is an = important feature, and moreover that clients in particular may not have = online access to a certificate status server. For example, if a client = is logging into a corporate network and the certificate status server is = inside the corporate network, then the client cannot access the network = to verify the status of the certificate. Constraints: We did not include any SSH-specific constraints in our = draft. I have no opinion whether including such constraints is = appropriate or not, and there seems to be some discussion going on right = now about this. X.509 versus not X.509: Obviously the main difference is the certificate = format. We started from the premise that "people want to use their PKIX = infrastructure in SSH", and it appears, Damien, that you and your = colleagues started from the premise that "people want to use some kind = of certificates in SSH". But you've also later written in this thread: > Well, unfortunately we consider the additional complexity and attack = surface added by X.509 to be too great. Is it that you (a) consider all existing implementations of X.509 to be = too untested and thus have an unacceptable attack surface or (b) = consider the X.509 specification itself to be too complex to ever have = an acceptable implementation? If it's (a), then there's at least a hope = for reconciliation between our approach and yours. If it's (b), then to = me that says the maintainers of the most popular SSH implementation will = not ever accept the use of X.509 certificates in SSH. Douglas On 2010-Mar-17, at 3:19 AM, Damien Miller wrote: > Hi, >=20 > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > user and host keys. These were designed to reuse SSH wire-encoding and > signature primitives to minimise the additional attack surface exposed > pre-auth. In particular, we are not comfortable with the complexity > (syntactically or sematically) of X.509. >=20 > Here is the document from the OpenSSH source distribution that = describes > them (PROTOCOL.certkeys). If there is interested from other = implementors > in interoperating with these certificates then I'm willing to write = this > up as an I-D. >=20 > -d >=20 > ------------------------ >=20 > This document describes a simple public-key certificate authentication > system for use by SSH. >=20 > Background > ---------- >=20 > The SSH protocol currently supports a simple public key authentication > mechanism. Unlike other public key implementations, SSH eschews the > use of X.509 certificates and uses raw keys. This approach has some > benefits relating to simplicity of configuration and minimisation > of attack surface, but it does not support the important use-cases > of centrally managed, passwordless authentication and centrally > certified host keys. >=20 > These protocol extensions build on the simple public key = authentication > system already in SSH to allow certificate-based authentication. > The certificates used are not traditional X.509 certificates, with > numerous options and complex encoding rules, but something rather > more minimal: a key, some identity information and usage constraints > that have been signed with some other trusted key. >=20 > A sshd server may be configured to allow authentication via certified > keys, by extending the existing ~/.ssh/authorized_keys mechanism > to allow specification of certification authority keys in addition > to raw user keys. The ssh client will support automatic verification > of acceptance of certified host keys, by adding a similar ability > to specify CA keys in ~/.ssh/known_hosts. >=20 > Certified keys are represented using two new key types: > ssh-rsa-cert-v00@openssh.com and ssh-dss-cert-v00@openssh.com that > include certification information along with the public key that is = used > to sign challenges. ssh-keygen performs the CA signing operation. >=20 > Protocol extensions > ------------------- >=20 > The SSH wire protocol includes several extensibility mechanisms. > These modifications shall take advantage of namespaced public key > algorithm names to add support for certificate authentication without > breaking the protocol - implementations that do not support the > extensions will simply ignore them. >=20 > Authentication using the new key formats described below proceeds > using the existing SSH "publickey" authentication method described > in RFC4252 section 7. >=20 > New public key formats > ---------------------- >=20 > The ssh-rsa-cert-v00@openssh.com and ssh-dss-cert-v00@openssh.com key > types take a similar high-level format (note: data types and > encoding are as per RFC4251 section 5). The serialised wire encoding = of > these certificates is also used for storing them on disk. >=20 > #define SSH_CERT_TYPE_USER 1 > #define SSH_CERT_TYPE_HOST 2 >=20 > RSA certificate >=20 > string "ssh-rsa-cert-v00@openssh.com" > mpint e > mpint n > uint32 type > string key id > string valid principals > uint64 valid after > uint64 valid before > string constraints > string nonce > string reserved > string signature key > string signature >=20 > DSA certificate >=20 > string "ssh-dss-cert-v00@openssh.com" > mpint p > mpint q > mpint g > mpint y > uint32 type > string key id > string valid principals > uint64 valid after > uint64 valid before > string constraints > string nonce > string reserved > string signature key > string signature >=20 > e and n are the RSA exponent and public modulus respectively. >=20 > p, q, g, y are the DSA parameters as described in FIPS-186-2. >=20 > type specifies whether this certificate is for identification of a = user > or a host using a SSH_CERT_TYPE_... value. >=20 > key id is a free-form text field that is filled in by the CA at the = time > of signing; the intention is that the contents of this field are used = to > identify the identity principal in log messages. >=20 > "valid principals" is a string containing zero or more principals as > strings packed inside it. These principals list the names for which = this > certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates = and > usernames for SSH_CERT_TYPE_USER certificates. As a special case, a > zero-length "valid principals" field means the certificate is valid = for > any principal of the specified type. XXX DNS wildcards? >=20 > "valid after" and "valid before" specify a validity period for the > certificate. Each represents a time in seconds since 1970-01-01 > 00:00:00. A certificate is considered valid if: > valid after <=3D current time < valid before >=20 > constraints is a set of zero or more key constraints encoded as below. >=20 > The nonce field is a CA-provided random bitstring of arbitrary length > (but typically 16 or 32 bytes) included to make attacks that depend on > inducing collisions in the signature hash infeasible. >=20 > The reserved field is current unused and is ignored in this version of > the protocol. >=20 > signature key contains the CA key used to sign the certificate. > The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained" > certificates, where the signature key type is a certificate type = itself > are NOT supported. Note that it is possible for a RSA certificate key = to > be signed by a DSS CA key and vice-versa. >=20 > signature is computed over all preceding fields from the initial = string > up to, and including the signature key. Signatures are computed and > encoded according to the rules defined for the CA's public key = algorithm > (RFC4253 section 6.6 for ssh-rsa and ssh-dss). >=20 > Constraints > ----------- >=20 > The constraints section of the certificate specifies zero or more > constraints on the certificates validity. The format of this field > is a sequence of zero or more tuples: >=20 > string name > string data >=20 > The name field identifies the constraint and the data field encodes > constraint-specific information (see below). All constraints are > "critical", if an implementation does not recognise a constraint > then the validating party should refuse to accept the certificate. >=20 > The supported constraints and the contents and structure of their > data fields are: >=20 > Name Format Description > = --------------------------------------------------------------------------= --- > force-command string Specifies a command that is = executed > (replacing any the user specified = on the > ssh command-line) whenever this = key is > used for authentication. >=20 > permit-X11-forwarding empty Flag indicating that X11 = forwarding > should be permitted. X11 = forwarding will > be refused if this constraint is = absent. >=20 > permit-agent-forwarding empty Flag indicating that agent = forwarding > should be allowed. Agent = forwarding > must not be permitted unless this > constraint is present. >=20 > permit-port-forwarding empty Flag indicating that = port-forwarding > should be allowed. If this = constraint is > not present then no port = forwarding will > be allowed. >=20 > permit-pty empty Flag indicating that PTY = allocation > should be permitted. In the = absence of > this constraint PTY allocation = will be > disabled. >=20 > permit-user-rc empty Flag indicating that execution = of > ~/.ssh/rc should be permitted. = Execution > of this script will not be = permitted if > this constraint is not present. >=20 > source-address string Comma-separated list of source = addresses > from which this certificate is = accepted > for authentication. Addresses are > specified in CIDR format = (nn.nn.nn.nn/nn > or hhhh::hhhh/nn). > If this constraint is not present = then > certificates may be presented = from any > source address. >=20 > $OpenBSD: PROTOCOL.certkeys,v 1.3 2010/03/03 22:50:40 djm Exp $ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 17 05:48:31 2010 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 B40DD3A682F for ; Wed, 17 Mar 2010 05:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.601 X-Spam-Level: ** X-Spam-Status: No, score=2.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgajM4LAgpPs for ; Wed, 17 Mar 2010 05:48:31 -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 F3A773A6903 for ; Wed, 17 Mar 2010 05:48:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E4C6A63B136; Wed, 17 Mar 2010 12:48:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.swemel.ru (mail.swemel.ru [79.135.238.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 8253763B11B for ; Wed, 17 Mar 2010 12:48:34 +0000 (UTC) Received: from [10.1.200.221] (helo=mail.swemel.grp) by mail.swemel.ru with esmtp (Exim 4.69) (envelope-from ) id 1NrrbB-0000Hc-0p for ietf-ssh@netbsd.org; Wed, 17 Mar 2010 14:39:41 +0300 Received: from [10.1.200.208] ([10.1.200.208]) by mail.swemel.grp with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 14:43:05 +0300 Message-ID: <4BA0C09C.7010703@swemel.ru> Disposition-Notification-To: Konstantin Andreev Date: Wed, 17 Mar 2010 14:44:28 +0300 From: Konstantin Andreev Organization: Swemel JSC User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100119 Thunderbird/3.0 MIME-Version: 1.0 To: ietf-ssh@netbsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2010 11:43:05.0439 (UTC) FILETIME=[01E466F0:01CAC5C7] X-SA-Exim-Connect-IP: 10.1.200.221 X-SA-Exim-Mail-From: andreev@swemel.ru Subject: Re: OpenSSH certified keys X-SA-Exim-Version: 4.2.1 (built Thu, 26 Jun 2008 08:56:56 +0000) X-SA-Exim-Scanned: Yes (on mail.swemel.ru) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 16.03.10 20:19, Damien Miller wrote: > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > user and host keys. These were designed to reuse SSH wire-encoding and > signature primitives to minimise the additional attack surface exposed > pre-auth. In particular, we are not comfortable with the complexity > (syntactically or sematically) of X.509. I am not a security expert. I can only rely on protocols/solutions, that trustworthy experts assert to be secure, or authoritative government institution certifies as secure. What have I from this point of view ? I can be sure that X.509 PKIX was designed and reviewed by the best experts in the industry. I can be sure, that all details I have never heard about were taken into account. There are approved guides which help me reach the highest level of the X.509 security. Can I be sure that security protocol, designed by self-taught security experts, reaches that level of security or has not hidden defects? Nope. IMO, being "not comfortable" with X.509 features is not enough to reimplement the wheel... Best regards, -- Konstantin Andreev, software engineer. Swemel JSC. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 17 09:20:59 2010 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 A6EA528C0E6 for ; Wed, 17 Mar 2010 09:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 dTlKvRuS0UI2 for ; Wed, 17 Mar 2010 09:20:57 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 295EA28C0EE for ; Wed, 17 Mar 2010 09:19:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3F1D563B157; Wed, 17 Mar 2010 16:19:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet12.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id B182863B15F for ; Wed, 17 Mar 2010 16:19:13 +0000 (UTC) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2HGImgI018336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Mar 2010 16:18:49 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2HGIank007777; Wed, 17 Mar 2010 16:18:36 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 93600041268842644; Wed, 17 Mar 2010 09:17:24 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Mar 2010 09:17:24 -0700 Date: Wed, 17 Mar 2010 11:17:19 -0500 From: Nicolas Williams To: Damien Miller Cc: "denis bider \\(Bitvise\\)" , ietf-ssh@NetBSD.org Subject: Re: OpenSSH certified keys Message-ID: <20100317161719.GK14993@Sun.COM> References: <20100316185552.GP14993@Sun.COM> <6DC7CD40E2FA4226B671A6BF7F17C450@element> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BA100E8.0071,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Mar 17, 2010 at 10:58:13AM +1100, Damien Miller wrote: > On Tue, 16 Mar 2010, denis bider \(Bitvise\) wrote: > > > For OpenSSH, revocation is implemented as a simple list > > > of banned keys. [...] > > > > does this list of banned keys need to be manually deployed to each > > server, or does OpenSSH support a protocol for retrieving this list > > remotely? > > > > [...] > > The list of revoked keys is just a file on disk and OpenSSH implements > no special means to update it (so far). We could define some distribution > service or an online protocol to lookup key revocation status, possibly > as a SSH subsystem. Why repeat mistakes of the past? What is the point of this PKI scheme other than "ASN.1/BER/x.500/... is too complex"? Why should anyone do any work to help standardize a protocol that improves on predecessors in only one [debatable] manner while taking steps backwards relative to predecessors in several important aspects? Areas of this protocol's design that repeat mistakes of the past or where new mistakes are made: - extensibility and criticality - hash collision attacks - revocation - hierarchy/bridging - separation of online vs. off-line keys And there's a bevvy of sub-protocols missing, such as certificate singing requests. As for your protocol's simplicity, that's ephemeral -- or do you believe that your protocol can remain simple enough for your tastes should it become popular? The arguments over ASN.1's and BER/DER/CER's complexity are specious. ASN.1's syntax is hard to parse, but it's also easy to come up with alternatives that parse well. XER proves that by and large ASN.1 and XML schemas have equivalent expressive power. PER can be seen as a byte-aligned variant of XDR, with slight differences in the handling of optional sequence elements and choice selection. I'd argue that redundancy of encoding is the main source of vulnerabilities in encoding/decoding code, and that redundancy/verbosity is a problem for XML as well as BER, yet XML is all the rage. Perceived simplicity clearly matters for a lot of implementors, but that should not excuse the repetition of mistakes outside the choice of syntax and encoding. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 19 17:31:36 2010 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 E23F63A685B for ; Fri, 19 Mar 2010 17:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 YlCwEDrmUls0 for ; Fri, 19 Mar 2010 17:31:34 -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 58C523A672E for ; Fri, 19 Mar 2010 17:31:34 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 18FF363B121; Sat, 20 Mar 2010 00:31:39 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 3809663B101 for ; Sat, 20 Mar 2010 00:31:36 +0000 (UTC) Received: from element ([205.217.224.99]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 19 Mar 2010 20:31:57 -0400 Message-ID: From: "denis bider \(Bitvise\)" To: "Nicolas Williams" , "Damien Miller" Cc: References: <20100316185552.GP14993@Sun.COM> <6DC7CD40E2FA4226B671A6BF7F17C450@element> <20100317161719.GK14993@Sun.COM> In-Reply-To: <20100317161719.GK14993@Sun.COM> Subject: Re: OpenSSH certified keys Date: Fri, 19 Mar 2010 20:31:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Good points, Nicolas. More often than not, however, the quick and dirty implementation will succeed in the market simply because it's there and gets the job approximately done when the rigorous solution is still in its design phases. The ubiquity of Unix-like computer architecture is testament to this. Something like Smalltalk would have been rigorous and better, but the quick and dirty Unix was there and did the job approximately done faster. The market share of Windows is another bit of evidence. The question is, will users be satisfied enough with the OpenSSH certified keys format that we'll all have to implement it. If that happens, it is in our interest to help the OpenSSH team fix any spec problems before we have to implement something even less optimal than it otherwise could be. I would hope that users will not be satisfied with this solution and will demand a more rigorous implementation, but that remains to be seen. denis ----- Original Message ----- From: "Nicolas Williams" To: "Damien Miller" Cc: "denis bider \(Bitvise\)" ; Sent: Wednesday, March 17, 2010 12:17 Subject: Re: OpenSSH certified keys On Wed, Mar 17, 2010 at 10:58:13AM +1100, Damien Miller wrote: > On Tue, 16 Mar 2010, denis bider \(Bitvise\) wrote: > > > For OpenSSH, revocation is implemented as a simple list > > > of banned keys. [...] > > > > does this list of banned keys need to be manually deployed to each > > server, or does OpenSSH support a protocol for retrieving this list > > remotely? > > > > [...] > > The list of revoked keys is just a file on disk and OpenSSH implements > no special means to update it (so far). We could define some > distribution > service or an online protocol to lookup key revocation status, > possibly > as a SSH subsystem. Why repeat mistakes of the past? What is the point of this PKI scheme other than "ASN.1/BER/x.500/... is too complex"? Why should anyone do any work to help standardize a protocol that improves on predecessors in only one [debatable] manner while taking steps backwards relative to predecessors in several important aspects? Areas of this protocol's design that repeat mistakes of the past or where new mistakes are made: - extensibility and criticality - hash collision attacks - revocation - hierarchy/bridging - separation of online vs. off-line keys And there's a bevvy of sub-protocols missing, such as certificate singing requests. As for your protocol's simplicity, that's ephemeral -- or do you believe that your protocol can remain simple enough for your tastes should it become popular? The arguments over ASN.1's and BER/DER/CER's complexity are specious. ASN.1's syntax is hard to parse, but it's also easy to come up with alternatives that parse well. XER proves that by and large ASN.1 and XML schemas have equivalent expressive power. PER can be seen as a byte-aligned variant of XDR, with slight differences in the handling of optional sequence elements and choice selection. I'd argue that redundancy of encoding is the main source of vulnerabilities in encoding/decoding code, and that redundancy/verbosity is a problem for XML as well as BER, yet XML is all the rage. Perceived simplicity clearly matters for a lot of implementors, but that should not excuse the repetition of mistakes outside the choice of syntax and encoding. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 21 15:45:56 2010 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 153193A67B4 for ; Sun, 21 Mar 2010 15:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.381 X-Spam-Level: ** X-Spam-Status: No, score=2.381 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-Q-s1I9qktJ for ; Sun, 21 Mar 2010 15:45:55 -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 0EBC83A677D for ; Sun, 21 Mar 2010 15:45:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 37CA363B1E3; Sun, 21 Mar 2010 22:46:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 0AE6063B17B for ; Sun, 21 Mar 2010 22:45:58 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 07C174001F; Sun, 21 Mar 2010 21:39:51 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id F17C14002D; Sun, 21 Mar 2010 21:39:50 +0100 (CET) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id C6E1A4001F; Sun, 21 Mar 2010 21:39:50 +0100 (CET) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id o2LKdoFa011914; Sun, 21 Mar 2010 21:39:50 +0100 (MET) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id o2LKdnWB011913; Sun, 21 Mar 2010 21:39:49 +0100 (MET) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Damien Miller Cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH certified keys References: Date: Sun, 21 Mar 2010 21:39:49 +0100 In-Reply-To: (Damien Miller's message of "Wed, 17 Mar 2010 04:19:28 +1100 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for > user and host keys. These were designed to reuse SSH wire-encoding and > signature primitives to minimise the additional attack surface exposed > pre-auth. In particular, we are not comfortable with the complexity > (syntactically or sematically) of X.509. I don't have time to look into the details at the moment, but it makes a lot of sense to me to (1) use certificates, e.g., to use a single key to certify hostkeys for a set of machines in the same administrative domain, and to enable users to delegate limited access to other keys, and (2) avoid the x.509 mess. Since my plan (which I haven't got around to implementing in a long time) have been to support spki certificates, my first question is how this certificate structure relates to spki? In spki, one has a fairly simple machine that processes lists of certificates, and then one have to choose a representation for the application specific stuff as "tags" in the acl:s and certificates in such a way that the machine gives the desired semantics when processing them. E.g, I use hostkey acl:s of the form (acl (entry (subject (public-key (rsa-pkcs1-sha1 (n |AM2/AtKFQ83sG1QMOG2 TnKegZz8GSd7ZrO5yS3 2DBriPYSLPPoleXTC9U JIdA2YhN0vkXq3jWOkR enqVNapK4Iiaj354M68 RGYcE38QhBLo7Sz1+U/ MDHcD//Dwehn8NFBK02 h8LMuuw5D2+RAZDm7fy +oKSIPjL/D0hX+tGnZ7 1|) (e "#")))) (tag (ssh-hostkey se.liu.lysator.stalhein)))) Note the reversed dns name. This choice of representation in the tag makes it possible to use the prefix-feature in the spki machinery to use a certificate that allows a key to sign hostkeys for any machine in a given domain. I expect that the constraints you list can also be represented, with some trickery like above needed only for the source-address constraint. > The supported constraints and the contents and structure of their > data fields are: > > Name Format Description > ----------------------------------------------------------------------------- > force-command string Specifies a command that is executed > (replacing any the user specified on the > ssh command-line) whenever this key is > used for authentication. This constraint removes a capability (that of executing arbitrary commands). > permit-X11-forwarding empty Flag indicating that X11 forwarding > should be permitted. X11 forwarding will > be refused if this constraint is absent. While this and most of the other "constraints" *adds* a capability. Having both positive and negative constrints seems like it makes it less straightforward when combining all constraints in a certificate chain (which represents delegation of authority). In spki, all constraints sets limits on authority, and then when combining a chain of certificates the constraints applied to the key is simply the union of the constraints present in some certificate or in the top-level acl entry. The opposite model where all constraints adds capabilitis is equally simple, then one takes the intersection instead of union. But when you have both positive and negative constraints, then the certificate chain machinery has to be aware of the semantics of each constraint, which I think is one reason why x.509 is hairy. An alternative design would be either have allow-command (with some meachnism to specify "any", or more generally, somehow specify a set of allowed commands, e.g., specifying a command prefix or a regexp), or no-X11-forwarding. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 29 11:21:33 2010 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 901783A6AC3 for ; Mon, 29 Mar 2010 11:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psBPjkGsZUAR for ; Mon, 29 Mar 2010 11:21:32 -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 5D4983A6B23 for ; Mon, 29 Mar 2010 11:21:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D5A6E63B186; Mon, 29 Mar 2010 18:21:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id E63A363B1DB for ; Mon, 29 Mar 2010 18:21:33 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 6386743 for ietf-ssh@NetBSD.org; Mon, 29 Mar 2010 11:21:30 -0600 Message-ID: <4BB0E199.2060809@vandyke.com> Date: Mon, 29 Mar 2010 11:21:29 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Feedback on draft-igoe-secsh-x509v3-01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I just did a quick read-thru on this document and it looks pretty good. However, this paragraph from Section 2 was confusing: > o The individual certificates in the certificate chain MUST be > signed using only algorithms corresponding to public key > algorithms supported by the peer. The choice of signature > algorithm used by any given certificate is independent of the > signature algorithms chosen by other certificates in the chain. > However, verifiers SHOULD be prepared to receive certificate > chains that do not comply with this (in other words, using any > signature algorithms), and MAY verify a non-compliant chain if > they are able to do so. First off I think "MUST be signed using only algorithms" conflicts with "verifiers SHOULD be prepared" (or at least is confusing.) And secondly, as I noted before, we really don't have a good indication of what algorithms the peer supports. We know what algorithms the server has a hostkey for and what algorithms the client is willing to accept as a hostkey. But we don't actually know what algorithms either side supports for publickey authentication. I would suggest this paragraph be rewritten as something similar to this: o The only algorithms that can be guaranteed to be supported by the peer are those that were listed in "server_host_key_algorithms" of key exchange (See RFC 4253, Section 7.1, "Algorithm Negotiation"). Where possible, the individual certificates in the certificate chain SHOULD be restricted to the algorithms listed in "server_host_key_algorithms"; however, other algorithms are permitted. Verifiers MUST be prepared to receive certificate chains that use algorithms that were not listed in "server_host_key_algorithms", and indeed potentially algorithms that have no ssh equivalent. Such chains are more likely result in a failure than a chain which uses only the algorithms listed in "server_host_key_algorithms" Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 30 09:06:46 2010 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 A0CDB3A6ABB for ; Tue, 30 Mar 2010 09:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 77xS37GAL52h for ; Tue, 30 Mar 2010 09:06:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 46CA73A6A9D for ; Tue, 30 Mar 2010 09:06:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3AC6263B100; Tue, 30 Mar 2010 16:07:02 +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 1AD6C63B120 for ; Tue, 30 Mar 2010 16:06:59 +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 o2UF2kJR004599; Tue, 30 Mar 2010 15:02:46 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.3959); Tue, 30 Mar 2010 11:02: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: Feedback on draft-igoe-secsh-x509v3-01 Date: Tue, 30 Mar 2010 11:01:43 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A13@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: <4BB0E199.2060809@vandyke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on draft-igoe-secsh-x509v3-01 Thread-Index: AcrPbLHeCZiwbdu0SiaxOHhhcteIIAAqbB+w From: "Igoe, Kevin M." To: "Joseph Galbraith" , , "Douglas Stebila" X-OriginalArrivalTime: 30 Mar 2010 15:02:03.0343 (UTC) FILETIME=[F4CEBDF0:01CAD019] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Good suggetions. Given the existing SSH UserAuth SSH_MSG_USERAUTH_REQUEST and SSH_MSG_USERAUTH_SUCCESS/FAILURE protocol specified in sction 7 of RFC 4253,=20 the best we can do is mitigate the need for many rounds of REQUEST & FAILURE=20 messages. Your suggested text addresses that quite nicely. I'd like to soften the "Verifiers MUST" in the second paragraph to "Verifiers SHOULD". Some ssh servers are restricted to a very=20 limited set of authorized clients. In such a case, these users may have been issued certs specifically for this site. The server need only deal with the signature algorithms used in these certs,=20 eliminating the need to support a broad spectrum of signatures. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith > Sent: Monday, March 29, 2010 1:21 PM > To: ietf-ssh@NetBSD.org > Subject: Feedback on draft-igoe-secsh-x509v3-01 >=20 > I just did a quick read-thru on this document and it looks=20 > pretty good. >=20 > However, this paragraph from Section 2 was confusing: >=20 > > o The individual certificates in the certificate chain MUST be > > signed using only algorithms corresponding to public key > > algorithms supported by the peer. The choice of signature > > algorithm used by any given certificate is independent of the > > signature algorithms chosen by other certificates in=20 > the chain. > > However, verifiers SHOULD be prepared to receive certificate > > chains that do not comply with this (in other words, using any > > signature algorithms), and MAY verify a non-compliant chain if > > they are able to do so. >=20 > First off I think "MUST be signed using only algorithms"=20 > conflicts with "verifiers SHOULD be prepared" (or at least is=20 > confusing.) >=20 > And secondly, as I noted before, we really don't have a good=20 > indication of what algorithms the peer supports. We know=20 > what algorithms the server has a hostkey for and what=20 > algorithms the client is willing to accept as a hostkey. But=20 > we don't actually know what algorithms either side supports=20 > for publickey authentication. >=20 > I would suggest this paragraph be rewritten as something similar to > this: >=20 > o The only algorithms that can be guaranteed to be supported > by the peer are those that were listed in > "server_host_key_algorithms" of key exchange (See RFC 4253, > Section 7.1, "Algorithm Negotiation"). Where possible, the > individual certificates in the certificate chain SHOULD be > restricted to the algorithms listed in "server_host_key_algorithms"; > however, other algorithms are permitted. >=20 > Verifiers MUST be prepared to receive certificate chains that use > algorithms that were not listed in "server_host_key_algorithms", > and indeed potentially algorithms that have no ssh equivalent. > Such chains are more likely result in a failure than a chain > which uses only the algorithms listed in=20 > "server_host_key_algorithms" >=20 > Thanks, >=20 > Joseph >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 30 09:56:21 2010 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 7E2C43A686A for ; Tue, 30 Mar 2010 09:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlzBgC-JNOEV for ; Tue, 30 Mar 2010 09:56: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 4E3993A67F3 for ; Tue, 30 Mar 2010 09:56:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B7CB663B11A; Tue, 30 Mar 2010 16:56:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id CDB8563B100 for ; Tue, 30 Mar 2010 16:56:39 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 6392532; Tue, 30 Mar 2010 10:56:38 -0600 Message-ID: <4BB22D46.9070600@vandyke.com> Date: Tue, 30 Mar 2010 10:56:38 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Igoe, Kevin M." CC: ietf-ssh@NetBSD.org, Douglas Stebila Subject: Re: Feedback on draft-igoe-secsh-x509v3-01 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A13@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A13@MSIS-GH1-UEA06.corp.nsa.gov> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 3/30/2010 09:01, Igoe, Kevin M. wrote: > Good suggetions. Given the existing SSH UserAuth > SSH_MSG_USERAUTH_REQUEST > and SSH_MSG_USERAUTH_SUCCESS/FAILURE protocol specified in sction 7 of > RFC 4253, > the best we can do is mitigate the need for many rounds of REQUEST & > FAILURE > messages. Your suggested text addresses that quite nicely. > > I'd like to soften the "Verifiers MUST" in the second paragraph to > "Verifiers SHOULD". Some ssh servers are restricted to a very > limited set of authorized clients. In such a case, these users may > have been issued certs specifically for this site. The server > need only deal with the signature algorithms used in these certs, > eliminating the need to support a broad spectrum of signatures. Are you talking about a client/server combo specifically implemented only to work with each other, or are you talking about a generic client/server combo configured in a specific way? If it is the former, then they needn't comply to any standard. If it is the latter, I'm pretty sure that MUST/REQUIRED doesn't actually apply to site policy... so even if the draft says MUST, site policy can still disable a feature (like the required key exchange or encryption algorithms.) Basically, in terms of interoperability, if we allow one peer to send something, then it seems like we have to require the other peer to be able to parse it. Note that the proposed language doesn't require that the request succeed, only that the verifier MUST be prepared to receive such requests (and in fact the next sentence predicts increased failure rates for such requests.) All that said, if you feel strongly about SHOULD instead of MUST, I'm not going to run screaming from the room :-) Thanks, Joseph >> -----Original Message----- >> From: ietf-ssh-owner@NetBSD.org >> [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith >> Sent: Monday, March 29, 2010 1:21 PM >> To: ietf-ssh@NetBSD.org >> Subject: Feedback on draft-igoe-secsh-x509v3-01 >> >> I just did a quick read-thru on this document and it looks >> pretty good. >> >> However, this paragraph from Section 2 was confusing: >> >>> o The individual certificates in the certificate chain MUST be >>> signed using only algorithms corresponding to public key >>> algorithms supported by the peer. The choice of signature >>> algorithm used by any given certificate is independent of the >>> signature algorithms chosen by other certificates in >> the chain. >>> However, verifiers SHOULD be prepared to receive certificate >>> chains that do not comply with this (in other words, using any >>> signature algorithms), and MAY verify a non-compliant chain if >>> they are able to do so. >> >> First off I think "MUST be signed using only algorithms" >> conflicts with "verifiers SHOULD be prepared" (or at least is >> confusing.) >> >> And secondly, as I noted before, we really don't have a good >> indication of what algorithms the peer supports. We know >> what algorithms the server has a hostkey for and what >> algorithms the client is willing to accept as a hostkey. But >> we don't actually know what algorithms either side supports >> for publickey authentication. >> >> I would suggest this paragraph be rewritten as something similar to >> this: >> >> o The only algorithms that can be guaranteed to be supported >> by the peer are those that were listed in >> "server_host_key_algorithms" of key exchange (See RFC 4253, >> Section 7.1, "Algorithm Negotiation"). Where possible, the >> individual certificates in the certificate chain SHOULD be >> restricted to the algorithms listed in "server_host_key_algorithms"; >> however, other algorithms are permitted. >> >> Verifiers MUST be prepared to receive certificate chains that use >> algorithms that were not listed in "server_host_key_algorithms", >> and indeed potentially algorithms that have no ssh equivalent. >> Such chains are more likely result in a failure than a chain >> which uses only the algorithms listed in >> "server_host_key_algorithms" >> >> Thanks, >> >> Joseph >> From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 30 09:57:54 2010 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 536293A6896 for ; Tue, 30 Mar 2010 09:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06tf5ddbchJQ for ; Tue, 30 Mar 2010 09:57:52 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B800C3A686A for ; Tue, 30 Mar 2010 09:57:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BD7E463B119; Tue, 30 Mar 2010 16:58:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id EA61863B100 for ; Tue, 30 Mar 2010 16:58:16 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 6392545 for ietf-ssh@NetBSD.org; Tue, 30 Mar 2010 10:58:14 -0600 Message-ID: <4BB22DA6.4040909@vandyke.com> Date: Tue, 30 Mar 2010 10:58:14 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: More feedback on draft-igoe-secsh-x509v3-01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Sections 4 and 5 seem a little bit strange to me. After rereading them a couple of times, I'm still not sure that they actually clarify anything and they might confuse things. RFC 4253, Section 8, makes it pretty clear (I think) that what ever is sent as "server public host key and certificates" is K_S. Similarly, RFC 4252 is pretty clear that the the publickey blob can contain certificates. In section 4, not only do we not list all of the possible key exchange packets (we missed out listing the kexgss packet and of course any future kex methods) but we seemingly loosen up the requirements by saying "an enconding of the data structure..." I think both of these sections might be collapsed into one that reads something like: The publickey algorithms and encodings defined in this document SHOULD be accepted anyplace in the ssh2 protocol suite where publickeys are used, including, but not limited to hostkeys, publickey authentication and hostbased authentication. Where such a publickey is included in the dataset which is input to a hash algorithm, the exact bytes that are transmitted on the wire must be used as input to the hash functions. In particular, implementations MUST NOT omit any of the chain certificates or OCSP responses that were included on the wire, nor change encoding of the certificate or OCSP data. Otherwise hashes that are meant to be computed in parallel by both peers will have differing values. In Section 7, IANA Considerations, do we need to mention the oids defined in section 2.1.2? It looks like the arc used isn't under iana's control (Did I read that correctly?), so perhaps not. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 30 10:29:59 2010 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 8C14A3A683A for ; Tue, 30 Mar 2010 10:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.858 X-Spam-Level: X-Spam-Status: No, score=-8.858 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Pe-hHND00yAo for ; Tue, 30 Mar 2010 10:29:58 -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 88B5E3A67FB for ; Tue, 30 Mar 2010 10:29:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9F1AF63B100; Tue, 30 Mar 2010 17:30:23 +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 30CCD63B129 for ; Tue, 30 Mar 2010 17:30:20 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA20503; Tue, 30 Mar 2010 13:30:20 -0400 (EDT) From: der Mouse Message-Id: <201003301730.NAA20503@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, 30 Mar 2010 13:26:30 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Feedback on draft-igoe-secsh-x509v3-01 In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A13@MSIS-GH1-UEA06.corp.nsa.gov> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A13@MSIS-GH1-UEA06.corp.nsa.gov> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > I'd like to soften the "Verifiers MUST" in the second paragraph to > "Verifiers SHOULD". [...] >> Verifiers MUST be prepared to receive certificate chains that use >> algorithms that were not listed [...] I see no reason to soften this. Being prepared to receive certificate chains is not the same thing as being prepared to accept, verify, and authenticate using them. Or were you talking about a different paragraph and thus a different MUST? /~\ 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 Mar 30 12:45:03 2010 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 E765E3A6826 for ; Tue, 30 Mar 2010 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 8ZdNlVRQzGQM for ; Tue, 30 Mar 2010 12:45: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 47BD53A6807 for ; Tue, 30 Mar 2010 12:45:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F22F663B129; Tue, 30 Mar 2010 19:45:22 +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 6753B63B100 for ; Tue, 30 Mar 2010 19:45:20 +0000 (UTC) Received: from MSCS-GH1-UEA03.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id o2UJk2ha004078; Tue, 30 Mar 2010 19:46:03 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.3959); Tue, 30 Mar 2010 15:45:18 -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: Feedback on draft-igoe-secsh-x509v3-01 Date: Tue, 30 Mar 2010 15:45:13 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A15@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: <201003301730.NAA20503@Sparkle.Rodents-Montreal.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on draft-igoe-secsh-x509v3-01 Thread-Index: AcrQLq/8U1g9bgLgQPa45t4oZCrbXAACk8VA From: "Igoe, Kevin M." To: "der Mouse" , X-OriginalArrivalTime: 30 Mar 2010 19:45:18.0086 (UTC) FILETIME=[8676BA60:01CAD041] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list For sake of completeness, let me take a stab at what the I think is meant by the phrase "prepared to receive" in this context. "Prapared to receive" means the server is able to identify the type digital signature used within each cert in the certificate=20 chain and decide if it is capable of verfiying this flavor of =20 digital signature. If either=20 1) putative chain of certs isn't properly formed 2) the root authority is unaccpetable 3) the server you isn't able to handle one or more of the flavors of digital signatures being used 4) one or more of the signatures is invalid then the server should send a SSH_MSG_USERAUTH_FAILURE message. Sadly, RFC 4252 highly constrains the format of a SSH_MSG_USERAUTH_FAILURE message, limiting he feedback that can be given to the user as to why their authentication has failed. > 5.1. Responses to Authentication Requests > If the server rejects the authentication request, it MUST respond > with the following: >=20 > byte SSH_MSG_USERAUTH_FAILURE > name-list authentications that can continue > boolean partial success >=20 > The 'authentications that can continue' is a comma-separated name- > list of authentication 'method name' values that may productively > continue the authentication dialog. =20 > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of der Mouse > Sent: Tuesday, March 30, 2010 1:27 PM > To: ietf-ssh@NetBSD.org > Subject: Re: Feedback on draft-igoe-secsh-x509v3-01 >=20 > > I'd like to soften the "Verifiers MUST" in the second paragraph to=20 > > "Verifiers SHOULD". [...] > >> Verifiers MUST be prepared to receive certificate chains that use > >> algorithms that were not listed [...] >=20 > I see no reason to soften this. Being prepared to receive=20 > certificate chains is not the same thing as being prepared to=20 > accept, verify, and authenticate using them. >=20 > Or were you talking about a different paragraph and thus a=20 > different MUST? >=20 > /~\ 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 >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Mar 30 18:48:57 2010 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 394B43A67BD for ; Tue, 30 Mar 2010 18:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] 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 cm9nlmV2K072 for ; Tue, 30 Mar 2010 18:48:56 -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 D1F093A6774 for ; Tue, 30 Mar 2010 18:48:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AD41163B10C; Wed, 31 Mar 2010 01:49:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from shannon.crazycode.ca (shannon.crazycode.ca [173.203.208.70]) by mail.netbsd.org (Postfix) with ESMTP id 24CCC63B10B for ; Wed, 31 Mar 2010 01:49:15 +0000 (UTC) Received: from [131.181.103.22] (unknown [131.181.103.22]) (Authenticated sender: dstebila@crazycode.ca) by shannon.crazycode.ca (Postfix) with ESMTPSA id 4FAFD987DF; Wed, 31 Mar 2010 01:49:14 +0000 (UTC) Subject: Re: More feedback on draft-igoe-secsh-x509v3-01 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Douglas Stebila In-Reply-To: <4BB22DA6.4040909@vandyke.com> Date: Wed, 31 Mar 2010 11:49:10 +1000 Cc: ietf-ssh@NetBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B894D25-ACF2-4B35-9A1D-5F0DD0AB0F22@stebila.ca> References: <4BB22DA6.4040909@vandyke.com> To: Joseph Galbraith X-Mailer: Apple Mail (2.1078) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 2010-Mar-31, at 2:58 AM, Joseph Galbraith wrote: > Sections 4 and 5 seem a little bit strange to me. After rereading > them a couple of times, I'm still not sure that they actually > clarify anything and they might confuse things. >=20 > RFC 4253, Section 8, makes it pretty clear (I think) that > what ever is sent as "server public host key and certificates" > is K_S. Similarly, RFC 4252 is pretty clear that the the > publickey blob can contain certificates. >=20 > In section 4, not only do we not list all of the possible > key exchange packets (we missed out listing the kexgss > packet and of course any future kex methods) but > we seemingly loosen up the requirements by saying > "an enconding of the data structure..." >=20 > I think both of these sections might be collapsed into > one that reads something like: >=20 > The publickey algorithms and encodings defined in this > document SHOULD be accepted anyplace in the ssh2 > protocol suite where publickeys are used, including, > but not limited to hostkeys, publickey authentication > and hostbased authentication. Yes, that does seem like a better way of doing it, as apparently we have = missed out on a number of existing areas. However, I would like to be = able to list of all the existing areas where we believe it does apply in = order to give implementers an idea of what they need to change based on = current standards in order to adopt this (i.e., "including but not = limited to" type language). Can you help me put together an exhaustive = list of current areas? I believe they include: - in the SSH_MSG_USERAUTH_REQUEST message when "publickey" = authentication is used [RFC4252] - in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" = authentication is used [RFC4252] - in the SSH_MSG_KEXDH_REPLY message [RFC4253] - in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432] - in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462] - in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656] - in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656] > Where such a publickey is included in the dataset which > is input to a hash algorithm, the exact bytes that are > transmitted on the wire must be used as input to the > hash functions. In particular, implementations MUST NOT > omit any of the chain certificates or OCSP responses > that were included on the wire, nor change encoding > of the certificate or OCSP data. Otherwise hashes that > are meant to be computed in parallel by both peers will > have differing values. This is a good point. > In Section 7, IANA Considerations, do we need to mention > the oids defined in section 2.1.2? It looks like the > arc used isn't under iana's control (Did I read that > correctly?), so perhaps not. The point of that line in section 7 was to say that IANA does not need = to do anything about the OIDs. Perhaps an unnecessary line, but when it = goes through the various formal reviews later in the process they'll = tell us to take it out if they think so. Douglas= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 31 14:09:58 2010 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 E44F83A68BE for ; Wed, 31 Mar 2010 14:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 mhdsCXnX+bQO for ; Wed, 31 Mar 2010 14:09:58 -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 D53FA3A6894 for ; Wed, 31 Mar 2010 14:09:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B13D063B14E; Wed, 31 Mar 2010 21:10:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 889D563B14D for ; Wed, 31 Mar 2010 21:10:18 +0000 (UTC) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2VLAG1p007965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 17:10:16 -0400 (EDT) Date: Wed, 31 Mar 2010 17:10:15 -0400 From: Jeffrey Hutzelman To: Douglas Stebila , Joseph Galbraith cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: More feedback on draft-igoe-secsh-x509v3-01 Message-ID: <1F871E446F3F8664722179A2@minbar.fac.cs.cmu.edu> In-Reply-To: <8B894D25-ACF2-4B35-9A1D-5F0DD0AB0F22@stebila.ca> References: <4BB22DA6.4040909@vandyke.com> <8B894D25-ACF2-4B35-9A1D-5F0DD0AB0F22@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.217.198 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, March 31, 2010 11:49:10 AM +1000 Douglas Stebila wrote: >> The publickey algorithms and encodings defined in this >> document SHOULD be accepted anyplace in the ssh2 >> protocol suite where publickeys are used, including, >> but not limited to hostkeys, publickey authentication >> and hostbased authentication. > > Yes, that does seem like a better way of doing it, as apparently we have > missed out on a number of existing areas. However, I would like to be > able to list of all the existing areas where we believe it does apply in > order to give implementers an idea of what they need to change based on > current standards in order to adopt this (i.e., "including but not > limited to" type language). Public key algorithms are a fairly straightforward abstraction in the ssh protocol, and we defined two of them up front. Any implementor who doesn't already have this abstraction or something like it is beyond our help. I don't think it's necessary or appropriate for every document that defines a new algorithm or method to enumerate all the places where the abstraction is used. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 31 17:54:19 2010 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 D5E073A68B9 for ; Wed, 31 Mar 2010 17:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZuS8Af0GN7M for ; Wed, 31 Mar 2010 17:54: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 DD6DE3A67CC for ; Wed, 31 Mar 2010 17:54:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AD8D163B153; Thu, 1 Apr 2010 00:54:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 838C063B15A for ; Thu, 1 Apr 2010 00:54:39 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 6397734 for ietf-ssh@NetBSD.org; Wed, 31 Mar 2010 18:54:38 -0600 Message-ID: <4BB3EED0.1090206@vandyke.com> Date: Wed, 31 Mar 2010 18:54:40 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Still more feedback on draft-igoe-secsh-x509v3-01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list In section 2. X.509 Version 3 Certificates, we have: > o The self-signed certificate specifying the root authority MAY be > omitted. which seems to indicate that all certificates except the self-signed certificate at the root MUST be included. I'm not sure that's what we want (or if that was actually what was intended.) I think it would be better to say: o The chain encoded MAY be incomplete; it is usually not necessary to include the self-signed certificate specifying the root authority. It is NOT REQUIRED to specify any certificates other than the senders certificate. If the verifier has a trust anchor that is not the self signed root, these other certificates may not be needed. However, omitting certificates from the chain may make it more likely that certificate verification will fail because the verifier is not able to build a chain to a trusted anchor. I'm worried in particular that there might be cases where the signer doesn't have all the certificates necessary to chain to the root easily available. (I'm not sure if this is a real life use case or not.) If we do decide we want to REQUIRE all the certificates, I think we should change the paragraph referenced to make that clear: o The self-signed certificate specifying the root authority MEY be omitted. All other certificates in the chain up to the root authority MUST be included. Also, is there any correlation between certificates and OSCP responses? Currently, there is nothing that constrains the OCSP responses included to have anything to do with the certificate. Is there a need for more than one OCSP response per issuer? Would it make more sense to do: uint32 certificate-count string certificate string ocsp-response-from-certificate-issuer [1..certificate-count] Use a 0 length string if no OCSP response is available. I'm not sure whether this is a good idea or if I'm just showing my ignorance. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 31 19:42:48 2010 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 B2F5C3A6890 for ; Wed, 31 Mar 2010 19:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 Ut1jMHH8D+nn for ; Wed, 31 Mar 2010 19:42: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 688CC3A684A for ; Wed, 31 Mar 2010 19:42:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4324E63B156; Thu, 1 Apr 2010 02:43:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet12.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id C928063B151 for ; Thu, 1 Apr 2010 02:43:10 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o312h8Sp007873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Apr 2010 02:43:09 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2VK8Osx006404; Thu, 1 Apr 2010 02:43:07 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 136330241270089696; Wed, 31 Mar 2010 19:41:36 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Mar 2010 19:41:36 -0700 Date: Wed, 31 Mar 2010 21:41:31 -0500 From: Nicolas Williams To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01 Message-ID: <20100401024130.GZ4225@Sun.COM> References: <4BB3EED0.1090206@vandyke.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB3EED0.1090206@vandyke.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BB4083B.00D7,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Mar 31, 2010 at 06:54:40PM -0600, Joseph Galbraith wrote: > In section 2. X.509 Version 3 Certificates, we have: > > > o The self-signed certificate specifying the root authority MAY be > > omitted. > > which seems to indicate that all certificates except the self-signed > certificate at the root MUST be included. > > I'm not sure that's what we want (or if that was actually what was > intended.) > > I think it would be better to say: SSHv2 key exchange is not retriable, and there's not much room for negotiating trust anchors (what server cert to present to some client?). Not sending a chain that the client needs will mean having to reconnect, which is really obnoxious. In practice servers will mostly have a single cert per-hostname (at most one per-interface, including virtual interfaces). Even then, the certification path used by the server may not be one the client can validate, but at least the client should then be able to build its own certification path for the server's cert. There are probably going to be many implementations that are unable to build certification paths. Therefore it's crucial to at least have the option to send certificate chains. > o The chain encoded MAY be incomplete; it is usually not > necessary to include the self-signed certificate specifying > the root authority. > > It is NOT REQUIRED to specify any certificates other than > the senders certificate. If the verifier has a trust anchor > that is not the self signed root, these other certificates may > not be needed. However, omitting certificates from the chain > may make it more likely that certificate verification will fail > because the verifier is not able to build a chain to a trusted > anchor. We need to RECOMMEND sending the full chain (excluding the signer's TA). > I'm worried in particular that there might be cases where the > signer doesn't have all the certificates necessary to chain > to the root easily available. (I'm not sure if this is a > real life use case or not.) That's OK. The relying party should then know how to build certification paths. > If we do decide we want to REQUIRE all the certificates, I think > we should change the paragraph referenced to make that clear: Either REQUIRE or RECOMMEND, or make sending of cert chains optional. For userauth making the sending of cert chains optional is easy. For host authentication it's harder. > Also, is there any correlation between certificates and OSCP > responses? Currently, there is nothing that constrains > the OCSP responses included to have anything to do with the > certificate. I think just sending an OCSP Response for the EE cert should suffice. The OCSP Responses for the certs in the certificate validation path can be cached by peers, proxies. But if that's not likely, then yes, we should want to send one OCSP response per cert in the chain being sent. Nico --