From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Dec 3 07:33: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 4381328C120 for ; Fri, 3 Dec 2010 07:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 a4KTkp+OCmk2 for ; Fri, 3 Dec 2010 07:33:09 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 18D7C28C118 for ; Fri, 3 Dec 2010 07:33:09 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6911619D5ED; Fri, 3 Dec 2010 15:34:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mail.netbsd.org (Postfix) with SMTP id D58D819D565 for ; Fri, 3 Dec 2010 15:34:19 +0000 (UTC) Received: (qmail 84821 invoked from network); 3 Dec 2010 15:34:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=OIKILURf7vHFCdLy6bg+bW87EHvsNmwEEmrSGvIqnof+o8/skUfk1l+JdOZnyUDI0Ln+U74GbjLqC/uQd9oCGKn1DiyFLmh9XzBf59oJcVEI9iAZTFoL7bVJWw7qTxz5DWDlGe5Fs+pFjYnHaV5q0h9b7UbgneH7EMd7ygHX7Gs= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1291390459; bh=4IKP4sTmPN8fL494pGe8BGJIJEH5INekYYaHCjEqvkI=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=1ntaeAarY1zZLklXnQY/B14UiEBtsBl2YkYpa9J86k0DPZ2qK7VRiKAO5uB9kdbBlv3ObF4ZHfwz+9Tcn/aK24Sp5uTHiOX3A7iZZDzJA63NEXw+YKLpM8Zly3u+4VnkocnUcI+2ZPMMMK5B8cN4K/0MU3sUt7Ygnu+Ijs8Ifjs= Received: from [10.10.90.109] (michael.perrier@99.230.80.245 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 03 Dec 2010 07:34:18 -0800 PST X-Yahoo-SMTP: jwnZhV6swBCKnyXoUmXxEFPXKA40NLHFgWAbcwlCys0iXGfyy1CP X-YMail-OSG: P7ewfzMVM1lHJ5Kdl5jKLwdek7cNp.UdN092mre.ZDvwSJu yVbpwSg4CNB0H5qj2e_pxySR7pNleH54fGIZD2gaOsT_EExiyFx3uge_zBYB AcmODsRsAW.RAHzIGyph2meeEz0waKXwKjRWUS2P7jK.qraDzMz6kIVs9ee2 NvpKHxHM.5R7dGA5BCr3fecbnnP4p.J.q7DALJh.R9oK7bOCQq2iabeYNoIg F8Oo62eZA0P8IznWifawyY.PL4UjHlQtcLbIH610kxAm.hhoDY.LoDL0dhw0 xKW2CzGEsny2dOSFjJqUMrdU51gl1bZG7hrbK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CF90DFA.9080208@rogers.com> Date: Fri, 03 Dec 2010 10:34:18 -0500 From: Michael Perrier User-Agent: Thunderbird 2.0.0.24 (X11/20100623) MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: SSH Port Forwarding Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, We have setup a SSH communications between our Linux Server application (LSA) and our proprietary client application (CA). This communication is 2-way: data packets are sent back and forth between the LSA and the CA. We have setup OpenSSH on the LSA server using a non-standard port; the LSA is setup to listen to a unpublished public port on the server. The CA is setup using SSH client software and PortForwarding to the LSA's unpublished port. The communication works very well, it is fast, reliable and secure. For security auditing purposes, I need to record the CA's IP address. When I perform a NTOP on the socket structure from the ACCEPT statement in LSA, I get the OpenSSH IP address. Is there a way for me to obtain the CA's original IP address? Many thanks in advance, Michael From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 8 04:58:43 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 F14D73A6930 for ; Wed, 8 Dec 2010 04:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ODdAADOzdUoA for ; Wed, 8 Dec 2010 04:58:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id BA7683A691B for ; Wed, 8 Dec 2010 04:58:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8EDAA19D5D5; Wed, 8 Dec 2010 13:00:00 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id F2F8019D59C for ; Wed, 8 Dec 2010 12:59:50 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB8CxmQF027942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Dec 2010 12:59:50 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB8CQhnJ029730 for ; Wed, 8 Dec 2010 12:59:48 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 855857151291813185; Wed, 08 Dec 2010 04:59:45 -0800 Received: from rejewski (/10.18.138.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Dec 2010 04:59:44 -0800 Date: Wed, 8 Dec 2010 13:58:43 +0100 (CET) From: Jan Pechanec X-X-Sender: jp161948@rejewski To: ietf-ssh@netbsd.org Subject: Extension of the agent protocol for the PKCS#11 URI scheme Message-ID: 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, Oracle's implementation of the X.509 part[1] of the pubkey auth method in the SSH protocol works with a PKCS#11 URI scheme[2] and as with plain private keys in files, we allow individual keys to be added to the agent. For that, we need two new messages in the agent protocol: byte SSH2_AGENTC_ADD_PKCS11_KEY or SSH2_AGENTC_ADD_PKCS11_KEY_CONSTRAINED string PKCS#11 URI string pin string[] key_constraints we could reuse some existing messages, eg. put the URI into reader_id in SSH_AGENTC_ADD_SMARTCARD_KEY used by OpenSSH but that would be a hack. The way how OpenSSH works with keystores is different, all available keys from a PKCS#11 provider are used, if I read the code correctly. the agent protocol OpenSSH, SunSSH as its derivative, and quite a few other implementations use comes from the original ssh-1.x code. It seems to me that authfd.h and PROTOCOL.agent in the OpenSSH tarball is now the de facto place for others to read about the current state of the protocol. I tried to contact the OpenSSH team about possible update of the file but didn't get a reply. we would like to notify you about our intention to take two new agent protocol message numbers. While not a problem on a localhost, if we (Oracle) clashed with other implementations we could run into problems when using agent forwarding. For now, we use higher numbers to avoid possible clash with other extensions: #define SSH2_AGENTC_ADD_PKCS11_URI_KEY 62 #define SSH2_AGENTC_ADD_PKCS11_URI_KEY_CONSTRAINED 63 please let us now if the numbers we use clash with any implementation of yours or if you have any other concerns. thank you, Jan. [1] http://tools.ietf.org/id/draft-saarenmaa-ssh-x509-00.txt [2] http://www.ietf.org/id/draft-pechanec-pkcs11uri-03.txt -- Jan Pechanec http://blogs.sun.com/janp From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 8 04:58:43 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 925F33A691B for ; Wed, 8 Dec 2010 04:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.014, 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 oaAfOkleAiHu for ; Wed, 8 Dec 2010 04:58:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 7C41D3A692A for ; Wed, 8 Dec 2010 04:58:42 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DEB3A19D5C4; Wed, 8 Dec 2010 13:00:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id F341619D5C2 for ; Wed, 8 Dec 2010 12:59:50 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB8CxnWT027972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Dec 2010 12:59:50 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB8CQhnL029730 for ; Wed, 8 Dec 2010 12:59:48 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 855857151291813185; Wed, 08 Dec 2010 04:59:45 -0800 Received: from rejewski (/10.18.138.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Dec 2010 04:59:44 -0800 Date: Wed, 8 Dec 2010 13:58:43 +0100 (CET) From: Jan Pechanec X-X-Sender: jp161948@rejewski To: ietf-ssh@netbsd.org Subject: Extension of the agent protocol for the PKCS#11 URI scheme Message-ID: 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, Oracle's implementation of the X.509 part[1] of the pubkey auth method in the SSH protocol works with a PKCS#11 URI scheme[2] and as with plain private keys in files, we allow individual keys to be added to the agent. For that, we need two new messages in the agent protocol: byte SSH2_AGENTC_ADD_PKCS11_KEY or SSH2_AGENTC_ADD_PKCS11_KEY_CONSTRAINED string PKCS#11 URI string pin string[] key_constraints we could reuse some existing messages, eg. put the URI into reader_id in SSH_AGENTC_ADD_SMARTCARD_KEY used by OpenSSH but that would be a hack. The way how OpenSSH works with keystores is different, all available keys from a PKCS#11 provider are used, if I read the code correctly. the agent protocol OpenSSH, SunSSH as its derivative, and quite a few other implementations use comes from the original ssh-1.x code. It seems to me that authfd.h and PROTOCOL.agent in the OpenSSH tarball is now the de facto place for others to read about the current state of the protocol. I tried to contact the OpenSSH team about possible update of the file but didn't get a reply. we would like to notify you about our intention to take two new agent protocol message numbers. While not a problem on a localhost, if we (Oracle) clashed with other implementations we could run into problems when using agent forwarding. For now, we use higher numbers to avoid possible clash with other extensions: #define SSH2_AGENTC_ADD_PKCS11_URI_KEY 62 #define SSH2_AGENTC_ADD_PKCS11_URI_KEY_CONSTRAINED 63 please let us now if the numbers we use clash with any implementation of yours or if you have any other concerns. thank you, Jan. [1] http://tools.ietf.org/id/draft-saarenmaa-ssh-x509-00.txt [2] http://www.ietf.org/id/draft-pechanec-pkcs11uri-03.txt -- Jan Pechanec http://blogs.sun.com/janp From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 8 09:11:32 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 CFA3F3A6868 for ; Wed, 8 Dec 2010 09:11:32 -0800 (PST) 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 h173t+RaCNVq for ; Wed, 8 Dec 2010 09:11:31 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 720EF3A6817 for ; Wed, 8 Dec 2010 09:11:31 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 59CE319D5D8; Wed, 8 Dec 2010 17:12:56 +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 52DA119D568 for ; Wed, 8 Dec 2010 17:12:50 +0000 (UTC) Received: from [10.6.1.226] (unknown [203.117.19.120]) (Authenticated sender: dstebila@crazycode.ca) by shannon.crazycode.ca (Postfix) with ESMTPSA id 366CD980A3; Wed, 8 Dec 2010 10:58:25 -0500 (EST) From: Douglas Stebila Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Server authentication using X.509v3 certificates Date: Wed, 8 Dec 2010 23:53:59 +0800 Message-Id: <9E8EAE14-E0E8-4211-820B-367E3C9C770E@stebila.ca> Cc: Peter Saint-Andre To: ietf-ssh@netbsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list In the last call for draft-igoe-secsh-x509v3, Peter Saint-Andre has = suggested that a more concrete mechanism be used for specifying how = X.509v3 certificates map to server host names. With his help, we have = developed some suggested text, but would like the feedback of the SSH = standardization community on whether this mechanism is appropriate. The original text was: > For the purposes of server authentication, the mapping between > certificates and host names is left as an implementation and > configuration issue for implementers and system administrators. The newly proposed text (with contributions from Peter) is: > For the purposes of user authentication, the mapping between = certificates and user names is left as an implementation and = configuration issue for implementers and system administrators. >=20 > For the purposes of server authentication, it is RECOMMENDED that = implementations support the following mechanism mapping host names to = certificates. However, local policy MAY disable the mechanism or MAY = impose additional constraints before considering a matching successful. = Furthermore, additional mechanisms mapping host names to certificates = MAY be used and are left as implementation and configuration issues for = implementers and system administrators. >=20 > The RECOMMENDED server authentication mechanism is as follows. The = subjectAlternativeName X.509v3 extension [RFC5280, Section 4.2.1.6] = SHOULD be used to convey the server host name, using either dNSName = entries or iPAddress entries to convey domain names or IP addresses as = appropriate. Multiple entries MAY be specified. The following rules = apply: >=20 > o If the client's reference identifier (e.g., the host name typed by = the client) is a DNS domain name, the server's identity SHOULD be = checked using the rules specified in [TLS-CERTS]. Support for the = DNS-ID identifier type is RECOMMENDED in client and server software = implementations. Certification authorities that issue certificates for = use by Secure Shell servers SHOULD support the DNS-ID identifier type. = Service providers SHOULD include the DNS-ID identifier type in = certificate requests. The DNS-ID MAY contain the wildcard character '*' = as the complete left-most label within the identifier. >=20 > o If the client's reference identifier is an IP address as defined by = [RFC791] or [RFC2460], the client SHOULD convert that address to the = "network byte order" octet string representation and compare it against = a subjectAltName entry of type iPAddress. A match occurs if the octet = strings are identifier for the reference identifier and any presented = identifier. >=20 > [TLS-CERTS] = http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-11 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 8 10:24: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 9C1363A6826 for ; Wed, 8 Dec 2010 10:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 p9M-g9fowHrJ for ; Wed, 8 Dec 2010 10:24:46 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 97FAD3A6929 for ; Wed, 8 Dec 2010 10:24:43 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A8CAB19D59E; Wed, 8 Dec 2010 18:26:04 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "USERTrust Legacy Secure Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9022D19D488 for ; Wed, 8 Dec 2010 18:25:57 +0000 (UTC) Received: from [128.2.184.179] (JHUTZ-DYN2.PC.CS.CMU.EDU [128.2.184.179]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id oB8GjSwO022106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Dec 2010 11:45:28 -0500 (EST) Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme From: Jeffrey Hutzelman To: Jan Pechanec Cc: ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Dec 2010 11:45:28 -0500 Message-ID: <1291826728.3020.17.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 2010-12-08 at 13:58 +0100, Jan Pechanec wrote: > Oracle's implementation of the X.509 part[1] You should be aware that the referenced document is an expired internet-draft, and does not represent any part of the SSH protocol specification. It was one proposal for adding X.509 certificate support to SSH, but did not end up being adopted. In particular, you should be aware that the public key algorithm names mentioned in that document come from that portion of the namespace that is reserved for assignment by IANA according to the "IETF Consensus" policy, and appear in no registry. You should take a look at draft-igoe-secsh-x509v3-06.txt, which is currently in IESG review and is likely to come up again for discussion shortly on this mailing list, due to some changes that have been proposed. That said... > of the pubkey auth > method in the SSH protocol works with a PKCS#11 URI scheme[2] and as > with plain private keys in files, we allow individual keys to be added > to the agent. For that, we need two new messages in the agent protocol: > > byte SSH2_AGENTC_ADD_PKCS11_KEY or > SSH2_AGENTC_ADD_PKCS11_KEY_CONSTRAINED > string PKCS#11 URI > string pin > string[] key_constraints > > we could reuse some existing messages, eg. put the URI into > reader_id in SSH_AGENTC_ADD_SMARTCARD_KEY used by OpenSSH but that would > be a hack. The way how OpenSSH works with keystores is different, all > available keys from a PKCS#11 provider are used, if I read the code > correctly. IIRC, the existing smartcard support doesn't use PKCS#11 at all. The only implementation I've played with transmits both a reader ID (which is really what PKCS#11 would consider a single slot) and a key ID, so in fact only a single key is named. In any case, I agree that reusing those messages seems like a hack, and adding new messages may be more appropriate. I'd suggest doing something a bit more general, but I think the community has mostly settled on PKCS#11 as being the primary abstraction for this (which would be fine, if it didn't deal so poorly with dynamic changes in the number of slots). > the agent protocol OpenSSH, SunSSH as its derivative, and quite > a few other implementations use comes from the original ssh-1.x code. It > seems to me that authfd.h and PROTOCOL.agent in the OpenSSH tarball is > now the de facto place for others to read about the current state of the > protocol. I tried to contact the OpenSSH team about possible update of > the file but didn't get a reply. > > we would like to notify you about our intention to take two new > agent protocol message numbers. While not a problem on a localhost, if > we (Oracle) clashed with other implementations we could run into > problems when using agent forwarding. For now, we use higher numbers to > avoid possible clash with other extensions: > > #define SSH2_AGENTC_ADD_PKCS11_URI_KEY 62 > #define SSH2_AGENTC_ADD_PKCS11_URI_KEY_CONSTRAINED 63 > > please let us now if the numbers we use clash with any > implementation of yours or if you have any other concerns. I think it's a (past) mistake to think of the agent protocol as being something private, rather than something for which interoperability is desirable and therefore for which standardization is appropriate. I imagine if someone wanted to write an I-D documenting the protocol and setting up a registry for these values, that would be a good thing. Not that I'm volunteering, mind you. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 8 10:49:07 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 C99DC3A6988 for ; Wed, 8 Dec 2010 10:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, 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 La36vIOid0H7 for ; Wed, 8 Dec 2010 10:49:06 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id B43DC3A684F for ; Wed, 8 Dec 2010 10:49:06 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CA51119D56B; Wed, 8 Dec 2010 18:50:27 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id F383419D4D6 for ; Wed, 8 Dec 2010 18:50:22 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB8IoJos015107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Dec 2010 18:50:20 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB8IoIms011076; Wed, 8 Dec 2010 18:50:18 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 857119191291834215; Wed, 08 Dec 2010 10:50:15 -0800 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Dec 2010 10:50:14 -0800 Date: Wed, 8 Dec 2010 12:50:07 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Jan Pechanec , ietf-ssh@netbsd.org Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme Message-ID: <20101208185006.GA1099@oracle.com> References: <1291826728.3020.17.camel@destiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291826728.3020.17.camel@destiny> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Dec 08, 2010 at 11:45:28AM -0500, Jeffrey Hutzelman wrote: > On Wed, 2010-12-08 at 13:58 +0100, Jan Pechanec wrote: > > we could reuse some existing messages, eg. put the URI into > > reader_id in SSH_AGENTC_ADD_SMARTCARD_KEY used by OpenSSH but that would > > be a hack. The way how OpenSSH works with keystores is different, all > > available keys from a PKCS#11 provider are used, if I read the code > > correctly. > > IIRC, the existing smartcard support doesn't use PKCS#11 at all. The > only implementation I've played with transmits both a reader ID (which > is really what PKCS#11 would consider a single slot) and a key ID, so in > fact only a single key is named. In any case, I agree that reusing > those messages seems like a hack, and adding new messages may be more > appropriate. I'd suggest doing something a bit more general, but I > think the community has mostly settled on PKCS#11 as being the primary I agree as well that introducing new messages based on PKCS#11 is better than abusing the existing SSH_AGENTC_ADD_SMARTCARD_KEY message. > abstraction for this (which would be fine, if it didn't deal so poorly > with dynamic changes in the number of slots). A reasonably good solution is to pretend that there are many slots -- as many as might ever be expected to exist. But I agree, PKCS#11 is rather limited here. > > please let us now if the numbers we use clash with any > > implementation of yours or if you have any other concerns. > > I think it's a (past) mistake to think of the agent protocol as being > something private, rather than something for which interoperability is > desirable and therefore for which standardization is appropriate. I > imagine if someone wanted to write an I-D documenting the protocol and > setting up a registry for these values, that would be a good thing. Not > that I'm volunteering, mind you. That's why Jan posted this. There are multiple implementors, and we all like to make sure that our implementations interop. But we lack both, Standards-Track specifications and registries. Therefore posting here (and perhaps elsewhere?) seems like a reasonable way to pseudo-register protocol elements. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 8 11:04: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 93BB73A686A for ; Wed, 8 Dec 2010 11:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.357 X-Spam-Level: X-Spam-Status: No, score=-8.357 tagged_above=-999 required=5 tests=[AWL=1.631, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJS0uzxgvclR for ; Wed, 8 Dec 2010 11:04:41 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 296893A6823 for ; Wed, 8 Dec 2010 11:04:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0712519D5A5; Wed, 8 Dec 2010 19:06:06 +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 55FD719D555 for ; Wed, 8 Dec 2010 19:06:02 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA13966; Wed, 8 Dec 2010 14:06:01 -0500 (EST) Date: Wed, 8 Dec 2010 14:06:01 -0500 (EST) From: der Mouse Message-Id: <201012081906.OAA13966@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. X-Composition-Start-Date: Wed, 8 Dec 2010 13:54:34 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme In-Reply-To: <1291826728.3020.17.camel@destiny> References: <1291826728.3020.17.camel@destiny> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > I think it's a (past) mistake to think of the agent protocol as being > something private, rather than something for which interoperability > is desirable and therefore for which standardization is appropriate. > I imagine if someone wanted to write an I-D documenting the protocol > and setting up a registry for these values, that would be a good > thing. Not that I'm volunteering, mind you. At least one such I-D has existed; the IETF apparently thew away their copies(!), but http://www.vandyke.com/technology/draft-ietf-secsh-agent.txt has what looks like the latest version I know of. It's somewhat broken - perhaps most notably, it has an eight-bit field for which one of the specified values is 301 - but it's about the best I know of. It, or perhaps some other version of that draft, is what I wrote my agent implementation to. I am not willing to jump through the IETF's stupid I-D hoops (and, yes, I believe that's what they are), so I will not be resurrecting it as an I-D. I would cheerfully collaborate on the content if someone else wants to undertake the hoop-jumping. If not, I'll volunteer to host a non-IETF document; under those circumstances, that's about as close to a standard as we're likely to get. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 9 04:02:34 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 B98A13A6B00 for ; Thu, 9 Dec 2010 04:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 senwy550YgiM for ; Thu, 9 Dec 2010 04:02:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 65B203A6AF7 for ; Thu, 9 Dec 2010 04:02:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BC64519D652; Thu, 9 Dec 2010 12:03:55 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id BAFC319D659 for ; Thu, 9 Dec 2010 12:03:49 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB9C3iOK019642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 12:03:46 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 oB990FWj029424; Thu, 9 Dec 2010 12:03:43 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 839561621291896113; Thu, 09 Dec 2010 04:01:53 -0800 Received: from rejewski (/10.18.138.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Dec 2010 04:01:52 -0800 Date: Thu, 9 Dec 2010 13:00:59 +0100 (CET) From: Jan Pechanec X-X-Sender: jp161948@rejewski To: Jeffrey Hutzelman cc: ietf-ssh@NetBSD.org Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme In-Reply-To: <1291826728.3020.17.camel@destiny> Message-ID: References: <1291826728.3020.17.camel@destiny> 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, 8 Dec 2010, Jeffrey Hutzelman wrote: >On Wed, 2010-12-08 at 13:58 +0100, Jan Pechanec wrote: >> Oracle's implementation of the X.509 part[1] > >You should be aware that the referenced document is an expired >internet-draft, and does not represent any part of the SSH protocol >specification. It was one proposal for adding X.509 certificate support >to SSH, but did not end up being adopted. In particular, you should be >aware that the public key algorithm names mentioned in that document >come from that portion of the namespace that is reserved for assignment >by IANA according to the "IETF Consensus" policy, and appear in no >registry. hi, I'm aware of that. However, at least 4 different implementations support the original draft - VanDyke, Attachmate, Roumen Petrov's patch to OpenSSH, and Tectia (I think). We want to be compatible with such implementations. >You should take a look at draft-igoe-secsh-x509v3-06.txt, which is >currently in IESG review and is likely to come up again for discussion >shortly on this mailing list, due to some changes that have been >proposed. I know the draft and I hope it will become an RFC soon. As far as I know, no implementation supports it yet. It should not be difficult for us to add support for it in the future. [...] >IIRC, the existing smartcard support doesn't use PKCS#11 at all. The >only implementation I've played with transmits both a reader ID (which >is really what PKCS#11 would consider a single slot) and a key ID, so in >fact only a single key is named. In any case, I agree that reusing >those messages seems like a hack, and adding new messages may be more >appropriate. I'd suggest doing something a bit more general, but I >think the community has mostly settled on PKCS#11 as being the primary >abstraction for this (which would be fine, if it didn't deal so poorly >with dynamic changes in the number of slots). the original smartcard code was replaced with PKCS#11 support in OpenSSH 5.4. I guess you had worked with the orignal code. [...] >I think it's a (past) mistake to think of the agent protocol as being >something private, rather than something for which interoperability is >desirable and therefore for which standardization is appropriate. I >imagine if someone wanted to write an I-D documenting the protocol and >setting up a registry for these values, that would be a good thing. Not >that I'm volunteering, mind you. I agree. Before that happens, I think this alias is still the best communication channel for such things. thanks for comments, Jan. -- Jan Pechanec http://blogs.sun.com/janp From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 9 04:04:20 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 9386328C0E9 for ; Thu, 9 Dec 2010 04:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 i5Q298BhR-VU for ; Thu, 9 Dec 2010 04:04:14 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 8698E3A6B00 for ; Thu, 9 Dec 2010 04:04:09 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0D57119D65E; Thu, 9 Dec 2010 12:05:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 7E33619D638 for ; Thu, 9 Dec 2010 12:05:33 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB9C5TnU025865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 12:05:32 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB9C5RBW008521; Thu, 9 Dec 2010 12:05:28 GMT Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 859742751291896313; Thu, 09 Dec 2010 04:05:13 -0800 Received: from rejewski (/10.18.138.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Dec 2010 04:05:12 -0800 Date: Thu, 9 Dec 2010 13:04:19 +0100 (CET) From: Jan Pechanec X-X-Sender: jp161948@rejewski To: der Mouse cc: ietf-ssh@netbsd.org Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme In-Reply-To: <201012081906.OAA13966@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <1291826728.3020.17.camel@destiny> <201012081906.OAA13966@Sparkle.Rodents-Montreal.ORG> 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, 8 Dec 2010, der Mouse wrote: >> I think it's a (past) mistake to think of the agent protocol as being >> something private, rather than something for which interoperability >> is desirable and therefore for which standardization is appropriate. >> I imagine if someone wanted to write an I-D documenting the protocol >> and setting up a registry for these values, that would be a good >> thing. Not that I'm volunteering, mind you. > >At least one such I-D has existed; the IETF apparently thew away their >copies(!), but >http://www.vandyke.com/technology/draft-ietf-secsh-agent.txt has what >looks like the latest version I know of. It's somewhat broken - >perhaps most notably, it has an eight-bit field for which one of the >specified values is 301 - but it's about the best I know of. It, or >perhaps some other version of that draft, is what I wrote my agent >implementation to. hi, I found the document when looking for the write-ups of the protocol and this one seems to be quite different from what OpenSSH and many other implementations support. The differences are subtle but there are quite a few of them. For example, check format of SSH_AGENTC_ADD_RSA_IDENTITY versus SSH_AGENT_ADD_KEY. J. >I am not willing to jump through the IETF's stupid I-D hoops (and, yes, >I believe that's what they are), so I will not be resurrecting it as an >I-D. I would cheerfully collaborate on the content if someone else >wants to undertake the hoop-jumping. If not, I'll volunteer to host a >non-IETF document; under those circumstances, that's about as close to >a standard as we're likely to get. > >/~\ 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 > -- Jan Pechanec http://blogs.sun.com/janp From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 9 06:37:17 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 EA4AC28C0FF for ; Thu, 9 Dec 2010 06:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.9 X-Spam-Level: X-Spam-Status: No, score=-8.9 tagged_above=-999 required=5 tests=[AWL=1.088, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I8fIoepuvvU for ; Thu, 9 Dec 2010 06:37:13 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id 2539528B56A for ; Thu, 9 Dec 2010 06:37:13 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DA53B19D652; Thu, 9 Dec 2010 14:38:39 +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 CBAD619D5BE for ; Thu, 9 Dec 2010 14:38:36 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA24177; Thu, 9 Dec 2010 09:38:36 -0500 (EST) Date: Thu, 9 Dec 2010 09:38:36 -0500 (EST) From: der Mouse Message-Id: <201012091438.JAA24177@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. X-Composition-Start-Date: Thu, 9 Dec 2010 09:21:28 -0500 (EST) To: ietf-ssh@netbsd.org Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme In-Reply-To: References: <1291826728.3020.17.camel@destiny> <201012081906.OAA13966@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> http://www.vandyke.com/technology/draft-ietf-secsh-agent.txt > hi, I found the document when looking for the write-ups of the > protocol and this one seems to be quite different from what OpenSSH > and many other implementations support. The differences are subtle > but there are quite a few of them. For example, check format of > SSH_AGENTC_ADD_RSA_IDENTITY versus SSH_AGENT_ADD_KEY. I'd be interested to hear where I can find the documentation on this protocol OpenSSH &c speak. Are you talking about the stuff in http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD or is this something else? (I need to go through and figure out exactly what moussh implements; I don't recall whether I bothered to check whether the various bits of documentation I have agree with one another or not.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 9 07:03: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 1522528C129 for ; Thu, 9 Dec 2010 07:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 EyaUjc0a7P7C for ; Thu, 9 Dec 2010 07:03:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id B234628C0F3 for ; Thu, 9 Dec 2010 07:03:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4C6E319D674; Thu, 9 Dec 2010 15:05:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 7667719D656 for ; Thu, 9 Dec 2010 15:04:55 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB9F4rmg018625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 15:04:54 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB9F4quw026547; Thu, 9 Dec 2010 15:04:53 GMT Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 840110111291907079; Thu, 09 Dec 2010 07:04:39 -0800 Received: from rejewski (/10.18.138.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Dec 2010 07:04:29 -0800 Date: Thu, 9 Dec 2010 16:03:36 +0100 (CET) From: Jan Pechanec X-X-Sender: jp161948@rejewski To: der Mouse cc: ietf-ssh@netbsd.org Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme In-Reply-To: <201012091438.JAA24177@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <1291826728.3020.17.camel@destiny> <201012081906.OAA13966@Sparkle.Rodents-Montreal.ORG> <201012091438.JAA24177@Sparkle.Rodents-Montreal.ORG> 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 Thu, 9 Dec 2010, der Mouse wrote: >>> http://www.vandyke.com/technology/draft-ietf-secsh-agent.txt >> hi, I found the document when looking for the write-ups of the >> protocol and this one seems to be quite different from what OpenSSH >> and many other implementations support. The differences are subtle >> but there are quite a few of them. For example, check format of >> SSH_AGENTC_ADD_RSA_IDENTITY versus SSH_AGENT_ADD_KEY. > >I'd be interested to hear where I can find the documentation on this >protocol OpenSSH &c speak. Are you talking about the stuff in >http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD >or is this something else? (I need to go through and figure out >exactly what moussh implements; I don't recall whether I bothered to >check whether the various bits of documentation I have agree with one >another or not.) yes. I believe that PROTOCOL.agent file is the de facto place to read about the agent protocol that OpenSSH and others use. I haven't found it elsewhere. J. -- Jan Pechanec http://blogs.sun.com/janp From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 9 09:21: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 6C77E3A67B2 for ; Thu, 9 Dec 2010 09:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 4Kp0IqwDXsRF for ; Thu, 9 Dec 2010 09:21:58 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:216:3eff:fe67:11]) by core3.amsl.com (Postfix) with ESMTP id CE1963A682E for ; Thu, 9 Dec 2010 09:21:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9D3AB19D674; Thu, 9 Dec 2010 17:23:24 +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 "USERTrust Legacy Secure Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 541AF19D66B for ; Thu, 9 Dec 2010 17:23:20 +0000 (UTC) Received: from [128.2.184.179] (JHUTZ-DYN2.PC.CS.CMU.EDU [128.2.184.179]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id oB9FneKd007322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 10:49:41 -0500 (EST) Subject: Re: Extension of the agent protocol for the PKCS#11 URI scheme From: Jeffrey Hutzelman To: Jan Pechanec Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org In-Reply-To: References: <1291826728.3020.17.camel@destiny> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 10:49:41 -0500 Message-ID: <1291909781.5861.23.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit 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 Thu, 2010-12-09 at 13:00 +0100, Jan Pechanec wrote: > On Wed, 8 Dec 2010, Jeffrey Hutzelman wrote: > > >On Wed, 2010-12-08 at 13:58 +0100, Jan Pechanec wrote: > >> Oracle's implementation of the X.509 part[1] > > > >You should be aware that the referenced document is an expired > >internet-draft, and does not represent any part of the SSH protocol > >specification. It was one proposal for adding X.509 certificate support > >to SSH, but did not end up being adopted. In particular, you should be > >aware that the public key algorithm names mentioned in that document > >come from that portion of the namespace that is reserved for assignment > >by IANA according to the "IETF Consensus" policy, and appear in no > >registry. > > hi, I'm aware of that. However, at least 4 different > implementations support the original draft - VanDyke, Attachmate, Roumen > Petrov's patch to OpenSSH, and Tectia (I think). We want to be > compatible with such implementations. Fair enough. > >IIRC, the existing smartcard support doesn't use PKCS#11 at all. The > >only implementation I've played with transmits both a reader ID (which > >is really what PKCS#11 would consider a single slot) and a key ID, so in > >fact only a single key is named. In any case, I agree that reusing > >those messages seems like a hack, and adding new messages may be more > >appropriate. I'd suggest doing something a bit more general, but I > >think the community has mostly settled on PKCS#11 as being the primary > >abstraction for this (which would be fine, if it didn't deal so poorly > >with dynamic changes in the number of slots). > > the original smartcard code was replaced with PKCS#11 support in > OpenSSH 5.4. I guess you had worked with the orignal code. Indeed, I wasn't aware that such progress had been made. -- Jeff