From darrenm@sac.sfbay.sun.com Thu Aug 14 08:23:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EFNgY2019465 for ; Thu, 14 Aug 2008 08:23:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EFNfQO029772; Thu, 14 Aug 2008 08:23:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00D0JK3HDK00@brm-avmta-1.central.sun.com>; Thu, 14 Aug 2008 09:23:41 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00BREK3GF930@brm-avmta-1.central.sun.com>; Thu, 14 Aug 2008 09:23:40 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EFNdYM063505; Thu, 14 Aug 2008 08:23:39 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EFNbi5019460; Thu, 14 Aug 2008 08:23:37 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7EFNbaW019456; Thu, 14 Aug 2008 08:23:37 -0700 (PDT) Date: Thu, 14 Aug 2008 08:23:37 -0700 (PDT) From: Darren J Moffat Subject: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] To: psarc-ext@sun.com Cc: Jan.Pechanec@sun.com Message-id: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5178 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SunSSH with the OpenSSL PKCS#11 engine support 1.2. Name of Document Author/Supplier: Jan Pechanec 1.3. Date of This Document: 12/08/08 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.4. The name of your business unit: Security 1.5. Email Aliases: 1.5.1. Responsible Manager: Anup.Sekhar@Sun.COM 1.5.2. Responsible Engineer: Jan.Pechanec@Sun.COM 1.5.3. Marketing Manager: Mark.Thacker@Sun.COM 1.5.4. Interest List: security-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: SunSSH is a single threaded and CPU intensive application with regard to the symmetric encryption algorithms. If run on a machine with relatively slow CPU(s) the user experience is that the data transfer is very slow. Such machine is UltraSPARC T2, for example. The answer to this issue is to use crypto hardware accelerators through the OpenSSL API that SunSSH already uses. This project adds code that allows SunSSH to use the PKCS#11 engine that is integrated into OpenSSL version shipped with Solaris. The engine will be set on by default so that users get the speed-up without any need to configure it. On machines with no crypto HW accelerators the speed of the data transfer will stay the same. There will be a way to switch off any offloading of crypto operations to the PKCS#11 engine using a new option, UseOpenSSLEngine. 2.2. Risks and Assumptions: None. 3. Business Summary 3.1. Problem Area: Customers consider SunSSH slow on Niagara 2 machine or consider Niagara 2 machines slow in general when they test the data transfer speed with SunSSH. 3.3. Business Justification: People who try out UltraSPARC T2 machines very often test the machine by transfering a large amount of data over SSH, expecting it to perform reasonably fast due to an expected use of HW accelerators. However, the reality is that it's significantly slower than expected. For example, the data transfer speed is 2.5x slower than between 2 AMD64 machines with 2.4GHz CPUs. As a result of this test, many people consider machines based on UltraSPARC T2 CPU slow in general. 4. Technical Description: 4.1. Details: SunSSH will load the PKCS#11 engine based on the configuration option UseOpenSSLEngine. This option will be "yes" by default. The reason for introducing this option is that possible bug in a driver, a 3rd party crypto card for example, could cause SunSSH to be unusable. In that case, setting UseOpenSSLEngine to "no" will rollback to native OpenSSL crypto code only. Since we ship OpenSSL with one engine only we introduce just one new option. If we offer more engines in the future suitable for the use with SunSSH, we will introduce another option, probably called OpenSSLEngine, to hold the specific engine name. This project speeds up the data transfer on UltraSPARC T2 by 2.5x. To avoid any confusion, that means that a data transfer that took 50 seconds on UltraSPARC T2 takes 20 seconds now on the same machine. That's similar to a data transfer speed between 2 AMD64 2.4GHz machines. It doesn't matter whether the data is transfered over ssh(1) through a pipe (dd if=... | ssh ... "cat > xxx"), using scp(1) or sftp(1). All cases are accelerated; note that both scp(1) and sftp(1) use ssh(1) as a transport layer. 4.2. Bug/RFE Number(s): the project implements this RFE: 6445288 ssh needs to be OpenSSL engine aware I'll fix following SunSSH CRs as part of this project: 6709963 SunSSH leaks memory during initialization 6687401 ssh monitor shouldn't try to log remote IP when child closed the pipe 6696629 sshd should remove alarm signal handler after authentication and these which were filed against the Cryptographic Framework: 6674088 userland threshold for hw offloading makes it difficult for SSL and SSH protocols 6728450 6708125 prevents parent to use the Crypto Framework after the fork(2) 4.5. Interfaces: - we do NOT add any new command line option. - we add new UseOpenSSLEngine option keyword to both sshd and ssh (for use in sshd_config and ssh_config configuration files, respectively, or with "-o" command line option). 4.6. Doc Impact: Manual pages for sshd_config(5) and ssh_config(5) will be changed. The draft for the new option section follows: UseOpenSSLEngine Specifies whether sshd should use the OpenSSL PKCS#11 engine for offloading cryptographic operations to the Cryptographic Framework. Cryptographic operations are accelerated according to the the available installed plug-ins. When no suitable plug-ins are present this option will not have any effect. The default is yes. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From gdamore@sun.com Thu Aug 14 08:39:32 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EFdW6k019806 for ; Thu, 14 Aug 2008 08:39:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EFdUHC005185 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Aug 2008 08:39:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00001KTVYF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 08:39:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00I2JKTVV880@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 08:39:31 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EFdVHV014108 for ; Thu, 14 Aug 2008 08:39:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00G01KHSJ300@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 08:39:31 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L0027TKTJSC70@fe-sfbay-09.sun.com>; Thu, 14 Aug 2008 08:39:19 -0700 (PDT) Date: Thu, 14 Aug 2008 08:33:31 -0700 From: "Garrett D'Amore" Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <48A4504B.9030401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 6877 Why are we using OpenSSL for this instead of PKCS#11? Is SunSSH already using OpenSSL (without engine support)? If all things were equal (and I'm not saying they are), I'd think direct access to PKCS#11 would be preferable, since it would reduce layering induced overhead, and might offer additional configuration options. One of the PKCS#11 configuration options that might be really cool to have, for example, would be support for PKCS#11 secure key management. (I.e. allow me to store my private keys securely in a FIPS-140-2 compliant crypto device such as SCA 6000.) It isn't clear to me that this is easy (or feasible) with an OpenSSL layered approach. It seems like this project is only offer the acceleration benefit for hardware crypto, and not offering any key handling improvements, right? Also, what are the "compatibility" concerns of the new configuration file directive? What will happen to other open source implementations of SSH when they see the same directive (such as when sharing a home directory via NFS with Linux or FreeBSD systems)? Finally, might it not be a better choice to avoid hardcoding the notion of OpenSSL into the configuration file syntax? Perhaps something more generic, such as "UseHardwareOffload" or somesuch might be better, especially if the software might one day be changed to use a different crypto backend (such as PKCS#11.) -- Garrett Darren J Moffat wrote: > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > > SunSSH with the OpenSSL PKCS#11 engine support > > 1.2. Name of Document Author/Supplier: > > Jan Pechanec > > 1.3. Date of This Document: > > 12/08/08 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > 1.4.2. The ARC(s) you expect to review your project: > > PSARC > > 1.4.4. The name of your business unit: > > Security > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: Anup.Sekhar@Sun.COM > 1.5.2. Responsible Engineer: Jan.Pechanec@Sun.COM > 1.5.3. Marketing Manager: Mark.Thacker@Sun.COM > 1.5.4. Interest List: security-discuss@opensolaris.org > > > 2. Project Summary > 2.1. Project Description: > > SunSSH is a single threaded and CPU intensive application with regard to > the symmetric encryption algorithms. If run on a machine with relatively > slow CPU(s) the user experience is that the data transfer is very slow. > Such machine is UltraSPARC T2, for example. The answer to this issue is > to use crypto hardware accelerators through the OpenSSL API that SunSSH > already uses. > > This project adds code that allows SunSSH to use the PKCS#11 engine that > is integrated into OpenSSL version shipped with Solaris. The engine will > be set on by default so that users get the speed-up without any need to > configure it. On machines with no crypto HW accelerators the speed of > the data transfer will stay the same. There will be a way to switch off > any offloading of crypto operations to the PKCS#11 engine using a new > option, UseOpenSSLEngine. > > 2.2. Risks and Assumptions: > > None. > > > 3. Business Summary > 3.1. Problem Area: > > Customers consider SunSSH slow on Niagara 2 machine or consider Niagara > 2 machines slow in general when they test the data transfer speed with > SunSSH. > > 3.3. Business Justification: > > People who try out UltraSPARC T2 machines very often test the machine by > transfering a large amount of data over SSH, expecting it to perform > reasonably fast due to an expected use of HW accelerators. However, the > reality is that it's significantly slower than expected. For example, > the data transfer speed is 2.5x slower than between 2 AMD64 machines > with 2.4GHz CPUs. As a result of this test, many people consider > machines based on UltraSPARC T2 CPU slow in general. > > 4. Technical Description: > 4.1. Details: > > SunSSH will load the PKCS#11 engine based on the configuration option > UseOpenSSLEngine. This option will be "yes" by default. The reason for > introducing this option is that possible bug in a driver, a 3rd party > crypto card for example, could cause SunSSH to be unusable. In that > case, setting UseOpenSSLEngine to "no" will rollback to native OpenSSL > crypto code only. > > Since we ship OpenSSL with one engine only we introduce just one new > option. If we offer more engines in the future suitable for the use with > SunSSH, we will introduce another option, probably called OpenSSLEngine, > to hold the specific engine name. > > This project speeds up the data transfer on UltraSPARC T2 by 2.5x. To > avoid any confusion, that means that a data transfer that took 50 > seconds on UltraSPARC T2 takes 20 seconds now on the same machine. > That's similar to a data transfer speed between 2 AMD64 2.4GHz machines. > It doesn't matter whether the data is transfered over ssh(1) through a > pipe (dd if=... | ssh ... "cat > xxx"), using scp(1) or sftp(1). All > cases are accelerated; note that both scp(1) and sftp(1) use ssh(1) as a > transport layer. > > 4.2. Bug/RFE Number(s): > > the project implements this RFE: > > 6445288 ssh needs to be OpenSSL engine aware > > I'll fix following SunSSH CRs as part of this project: > > 6709963 SunSSH leaks memory during initialization > 6687401 ssh monitor shouldn't try to log remote IP when child > closed the pipe > 6696629 sshd should remove alarm signal handler after > authentication > > and these which were filed against the Cryptographic Framework: > > 6674088 userland threshold for hw offloading makes it difficult > for SSL and SSH protocols > 6728450 6708125 prevents parent to use the Crypto Framework > after the fork(2) > > 4.5. Interfaces: > > - we do NOT add any new command line option. > > - we add new UseOpenSSLEngine option keyword to both sshd and ssh (for > use in sshd_config and ssh_config configuration files, respectively, > or with "-o" command line option). > > 4.6. Doc Impact: > > Manual pages for sshd_config(5) and ssh_config(5) will be changed. The > draft for the new option section follows: > > > UseOpenSSLEngine > > Specifies whether sshd should use the OpenSSL PKCS#11 > engine for offloading cryptographic operations to the > Cryptographic Framework. Cryptographic operations are > accelerated according to the the available installed > plug-ins. When no suitable plug-ins are present this > option will not have any effect. The default is yes. > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > From Darren.Moffat@Sun.COM Thu Aug 14 08:44:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EFihYk019865 for ; Thu, 14 Aug 2008 08:44:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EFievq023960 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Aug 2008 16:44:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00105L2G4G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Aug 2008 08:44:40 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IBVL2EV880@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Aug 2008 08:44:40 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EFic1X020342 for ; Thu, 14 Aug 2008 15:44:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00201KYHNE00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Aug 2008 16:44:38 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00I92L2D3900@fe-emea-09.sun.com>; Thu, 14 Aug 2008 16:44:38 +0100 (BST) Date: Thu, 14 Aug 2008 16:44:37 +0100 From: Darren J Moffat Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A4504B.9030401@sun.com> Sender: Darren.Moffat@Sun.COM To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@Sun.COM, Jan.Pechanec@Sun.COM Message-id: <48A452E5.5070303@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 2275 Garrett D'Amore wrote: > Why are we using OpenSSL for this instead of PKCS#11? Is SunSSH already > using OpenSSL (without engine support)? Yes it already uses the libcrypto from OpenSSL. > If all things were equal (and I'm not saying they are), I'd think direct > access to PKCS#11 would be preferable, since it would reduce layering > induced overhead, and might offer additional configuration options. It would but we can do this project now or the bigger project much later. > One of the PKCS#11 configuration options that might be really cool to > have, for example, would be support for PKCS#11 secure key management. > (I.e. allow me to store my private keys securely in a FIPS-140-2 > compliant crypto device such as SCA 6000.) It isn't clear to me that > this is easy (or feasible) with an OpenSSL layered approach. It is actually possible and Jan, myself and Ferenc have worked out how to do it. > It seems like this project is only offer the acceleration benefit for > hardware crypto, and not offering any key handling improvements, right? Correct that is what is is all about. The main focus is on the UltraSPARC T2 processor which is just an accelerator anyway - it has no hardware keystore. > Also, what are the "compatibility" concerns of the new configuration > file directive? What will happen to other open source implementations > of SSH when they see the same directive (such as when sharing a home > directory via NFS with Linux or FreeBSD systems)? We already have that problem. The workaround is to use the per system /etc/ssh/ssh_config. > Finally, might it not be a better choice to avoid hardcoding the notion > of OpenSSL into the configuration file syntax? Perhaps something more > generic, such as "UseHardwareOffload" or somesuch might be better, > especially if the software might one day be changed to use a different > crypto backend (such as PKCS#11.) This was on purpose because it is about using the OpenSSL engine. If we do a direct PKCS#11 interface in the future the configuration required will be more than just a boolean. Also if we switch to direct PKCS#11 then hardware vs software doesn't make much sense, what makes sense is which PKCS#11 slot/token is being used. -- Darren J Moffat From Nicolas.Williams@sun.com Thu Aug 14 09:05:28 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EG5SLF020519 for ; Thu, 14 Aug 2008 09:05:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EG57Gp005072; Thu, 14 Aug 2008 10:05:24 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00149M10TH00@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Aug 2008 09:05:24 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IXYM0XV790@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Aug 2008 09:05:21 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7EG5Kj9017490; Thu, 14 Aug 2008 11:05:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7EG5KBb017489; Thu, 14 Aug 2008 11:05:20 -0500 (CDT) Date: Thu, 14 Aug 2008 11:05:19 -0500 From: Nicolas Williams Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A452E5.5070303@Sun.COM> To: Darren J Moffat Cc: "Garrett D'Amore" , Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Mail-followup-to: Darren J Moffat , Garrett D'Amore , Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <20080814160519.GA25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1409 On Thu, Aug 14, 2008 at 04:44:37PM +0100, Darren J Moffat wrote: > Garrett D'Amore wrote: > >Also, what are the "compatibility" concerns of the new configuration > >file directive? What will happen to other open source implementations > >of SSH when they see the same directive (such as when sharing a home > >directory via NFS with Linux or FreeBSD systems)? > > We already have that problem. The workaround is to use the per system > /etc/ssh/ssh_config. Also, the default value is good enough that I doubt anyone will actually use this option. > >Finally, might it not be a better choice to avoid hardcoding the notion > >of OpenSSL into the configuration file syntax? Perhaps something more > >generic, such as "UseHardwareOffload" or somesuch might be better, > >especially if the software might one day be changed to use a different > >crypto backend (such as PKCS#11.) > > This was on purpose because it is about using the OpenSSL engine. If we > do a direct PKCS#11 interface in the future the configuration required > will be more than just a boolean. Also if we switch to direct PKCS#11 > then hardware vs software doesn't make much sense, what makes sense is > which PKCS#11 slot/token is being used. Of course, a switch to use PKCS#11 directly will render this option obsolete. So, what is the interface stability of this option? (I propose Obsolete Committed.) Nico -- From Darren.Moffat@sun.com Thu Aug 14 09:09:16 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EG9Bos020783 for ; Thu, 14 Aug 2008 09:09:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EG99Nh017548 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 09:09:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00015M7A8H00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 09:09:10 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00GKMM78R770@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 09:09:09 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EG98sV000087 for ; Thu, 14 Aug 2008 16:09:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00301LZMXV00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 17:09:08 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00IXAM703900@fe-emea-09.sun.com>; Thu, 14 Aug 2008 17:09:02 +0100 (BST) Date: Thu, 14 Aug 2008 17:09:00 +0100 From: Darren J Moffat Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <20080814160519.GA25547@Sun.COM> Sender: Darren.Moffat@sun.com To: Darren J Moffat , "Garrett D'Amore" , Darren J Moffat , psarc-ext@sun.com, Jan.Pechanec@sun.com Message-id: <48A4589C.8050608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> <20080814160519.GA25547@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 420 Nicolas Williams wrote: > Of course, a switch to use PKCS#11 directly will render this option > obsolete. So, what is the interface stability of this option? (I > propose Obsolete Committed.) Nope, for now it is Committed. If we do direct calls to PKCS#11 then that case will deal with what to do with the options introduced in this case (likely mark them Obsolete and silently ignore them). -- Darren J Moffat From Jan.Pechanec@sun.com Thu Aug 14 10:17:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EHHhaZ024424 for ; Thu, 14 Aug 2008 10:17:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EHHbKW003000 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Aug 2008 18:17:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L0040NPDHTK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:17:41 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IVJPDFVHD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:17:40 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EHHdKr003991 for ; Thu, 14 Aug 2008 17:17:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00B01P6R9X00@fe-emea-10.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:17:39 +0100 (BST) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00EJRPDEMN90@fe-emea-10.sun.com>; Thu, 14 Aug 2008 18:17:38 +0100 (BST) Date: Thu, 14 Aug 2008 19:17:09 +0200 (CEST) From: Jan Pechanec Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A4504B.9030401@sun.com> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@fossa.czech.sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> Status: RO Content-Length: 1575 On Thu, 14 Aug 2008, Garrett D'Amore wrote: hi, > If all things were equal (and I'm not saying they are), I'd think direct access > to PKCS#11 would be preferable, since it would reduce layering induced > overhead, and might offer additional configuration options. another reason why we can't do it now is that the softtoken is slower than OpenSSL code on quite a few platforms. The overhead of another layer (CF) also takes its price. For example, my tests on AMD64 showed regression around 15% in SSH data transfer in case of using the softtoken only. > One of the PKCS#11 configuration options that might be really cool to have, for > example, would be support for PKCS#11 secure key management. (I.e. allow me to > store my private keys securely in a FIPS-140-2 compliant crypto device such as > SCA 6000.) It isn't clear to me that this is easy (or feasible) with an > OpenSSL layered approach. unfortunately, OpenSSL ENGINE API allows to work with RSA keys only now. > Also, what are the "compatibility" concerns of the new configuration file > directive? What will happen to other open source implementations of SSH when > they see the same directive (such as when sharing a home directory via NFS with > Linux or FreeBSD systems)? aside from what Darren said, we have IgnoreIfUnknown option in Nevada, and it was also filed against OpenSSH. However, they haven't adopted it so far. Anyway, users won't be expected to use this option unless something goes wrong; normally they should be fine with the default value "yes". J. -- Jan Pechanec From gdamore@sun.com Thu Aug 14 10:18:17 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EHIHfC024471 for ; Thu, 14 Aug 2008 10:18:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EHI9ge032105 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Aug 2008 11:18:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00407PEFUI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:18:15 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00I7EPEFV7E0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:18:15 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EHIFEW026266 for ; Thu, 14 Aug 2008 10:18:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00H01P74BS00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:18:15 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00G3HPE8G990@fe-sfbay-10.sun.com>; Thu, 14 Aug 2008 10:18:08 -0700 (PDT) Date: Thu, 14 Aug 2008 10:12:20 -0700 From: "Garrett D'Amore" Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A452E5.5070303@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <48A46774.1030204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2717 Thank you for your clarifications, which were pretty much as I expected. My only question relates to your answer to the question about key management... are you saying you believe in the future you can add use of an alternate key store using the OpenSSL library? (That seems moderately surprising to me. And I recognize its "not this project".) -- Garrett Darren J Moffat wrote: > Garrett D'Amore wrote: >> Why are we using OpenSSL for this instead of PKCS#11? Is SunSSH >> already using OpenSSL (without engine support)? > > Yes it already uses the libcrypto from OpenSSL. > >> If all things were equal (and I'm not saying they are), I'd think >> direct access to PKCS#11 would be preferable, since it would reduce >> layering induced overhead, and might offer additional configuration >> options. > > It would but we can do this project now or the bigger project much > later. > >> One of the PKCS#11 configuration options that might be really cool to >> have, for example, would be support for PKCS#11 secure key >> management. (I.e. allow me to store my private keys securely in a >> FIPS-140-2 compliant crypto device such as SCA 6000.) It isn't clear >> to me that this is easy (or feasible) with an OpenSSL layered approach. > > It is actually possible and Jan, myself and Ferenc have worked out how > to do it. > >> It seems like this project is only offer the acceleration benefit for >> hardware crypto, and not offering any key handling improvements, right? > > Correct that is what is is all about. The main focus is on the > UltraSPARC T2 processor which is just an accelerator anyway - it has > no hardware keystore. > >> Also, what are the "compatibility" concerns of the new configuration >> file directive? What will happen to other open source >> implementations of SSH when they see the same directive (such as when >> sharing a home directory via NFS with Linux or FreeBSD systems)? > > We already have that problem. The workaround is to use the per system > /etc/ssh/ssh_config. > >> Finally, might it not be a better choice to avoid hardcoding the >> notion of OpenSSL into the configuration file syntax? Perhaps >> something more generic, such as "UseHardwareOffload" or somesuch >> might be better, especially if the software might one day be changed >> to use a different crypto backend (such as PKCS#11.) > > This was on purpose because it is about using the OpenSSL engine. If > we do a direct PKCS#11 interface in the future the configuration > required will be more than just a boolean. Also if we switch to > direct PKCS#11 then hardware vs software doesn't make much sense, what > makes sense is which PKCS#11 slot/token is being used. > From gdamore@sun.com Thu Aug 14 10:19:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EHJmqY024573 for ; Thu, 14 Aug 2008 10:19:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EHJe6Z004152 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 18:19:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00409PGYW400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 10:19:46 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IYXPGXVHD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 10:19:45 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EHJjOJ006734 for ; Thu, 14 Aug 2008 10:19:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00H01P74BS00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 10:19:45 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00GMQPGIG990@fe-sfbay-10.sun.com>; Thu, 14 Aug 2008 10:19:31 -0700 (PDT) Date: Thu, 14 Aug 2008 10:13:43 -0700 From: "Garrett D'Amore" Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A4589C.8050608@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <48A467C7.8080402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> <20080814160519.GA25547@Sun.COM> <48A4589C.8050608@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 581 Darren J Moffat wrote: > Nicolas Williams wrote: > >> Of course, a switch to use PKCS#11 directly will render this option >> obsolete. So, what is the interface stability of this option? (I >> propose Obsolete Committed.) > > Nope, for now it is Committed. If we do direct calls to PKCS#11 then > that case will deal with what to do with the options introduced in > this case (likely mark them Obsolete and silently ignore them). And, I'm happy with that since the option offers no semantic difference in behavior, only a performance optimization benefit. -- Garrett From gdamore@sun.com Thu Aug 14 10:20:54 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EHKrRO024593 for ; Thu, 14 Aug 2008 10:20:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EHKn5K005083 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 18:20:53 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00L1LPIRGR00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 11:20:51 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00B6BPIPFEF0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 11:20:50 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EHKnn4026594 for ; Thu, 14 Aug 2008 10:20:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00H01PAU6I00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 10:20:49 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00CTRPIPJ830@fe-sfbay-09.sun.com>; Thu, 14 Aug 2008 10:20:49 -0700 (PDT) Date: Thu, 14 Aug 2008 10:15:01 -0700 From: "Garrett D'Amore" Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A4589C.8050608@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <48A46815.80502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> <20080814160519.GA25547@Sun.COM> <48A4589C.8050608@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 692 Darren J Moffat wrote: > Nicolas Williams wrote: > >> Of course, a switch to use PKCS#11 directly will render this option >> obsolete. So, what is the interface stability of this option? (I >> propose Obsolete Committed.) > > Nope, for now it is Committed. If we do direct calls to PKCS#11 then > that case will deal with what to do with the options introduced in > this case (likely mark them Obsolete and silently ignore them). > One other thought... do we have a way to express (in manual pages, documentation, etc.) options that were added by Sun and unlikely to be portable to OpenSSH? It seems like that might be useful information for administrators to know. -- Garrett From Jan.Pechanec@sun.com Thu Aug 14 10:28:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EHSNrp024797 for ; Thu, 14 Aug 2008 10:28:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EHSL6F008308 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Aug 2008 18:28:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00807PVA7500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:28:22 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00G0MPV9R7F0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 10:28:21 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EHSKiv004409 for ; Thu, 14 Aug 2008 17:28:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00J01PSXXX00@fe-emea-10.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:28:20 +0100 (BST) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00EI3PV8MNC0@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:28:20 +0100 (BST) Date: Thu, 14 Aug 2008 19:27:51 +0200 (CEST) From: Jan Pechanec Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <48A46774.1030204@sun.com> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@fossa.czech.sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> <48A46774.1030204@sun.com> Status: RO Content-Length: 714 On Thu, 14 Aug 2008, Garrett D'Amore wrote: > Thank you for your clarifications, which were pretty much as I expected. My > only question relates to your answer to the question about key management... > are you saying you believe in the future you can add use of an alternate key > store using the OpenSSL library? (That seems moderately surprising to me. And > I recognize its "not this project".) there is a patch to our PKCS#11 engine code that adds support for accessing RSA keys by reference (label). I think we need to contact OpenSSL team about extending the ENGINE API before we could start using it from other applications, and integrate that new engine code into Solaris. J. -- Jan Pechanec From Jan.Pechanec@Sun.COM Thu Aug 14 10:32:26 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EHWPUw024984 for ; Thu, 14 Aug 2008 10:32:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7EHWL9q002818 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Aug 2008 01:32:24 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00M09Q1Y9R00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 11:32:22 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00LYAQ1WJ300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 11:32:21 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EHWKDo004563 for ; Thu, 14 Aug 2008 17:32:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00N01Q0V1300@fe-emea-10.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:32:20 +0100 (BST) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L00EP9Q1RMND0@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:32:16 +0100 (BST) Date: Thu, 14 Aug 2008 19:31:47 +0200 (CEST) From: Jan Pechanec Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@fossa.czech.sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> <48A46774.1030204@sun.com> Status: RO Content-Length: 854 On Thu, 14 Aug 2008, Jan Pechanec wrote: >> Thank you for your clarifications, which were pretty much as I expected. My >> only question relates to your answer to the question about key management... >> are you saying you believe in the future you can add use of an alternate key >> store using the OpenSSL library? (That seems moderately surprising to me. And >> I recognize its "not this project".) > > there is a patch to our PKCS#11 engine code that adds support for >accessing RSA keys by reference (label). I think we need to contact OpenSSL >team about extending the ENGINE API before we could start using it from >other applications, and integrate that new engine code into Solaris. forgot to mention that there is also "6479874 OpenSSL should support key by reference/hardware keystores" that discusses the issue. J. -- Jan Pechanec From gdamore@sun.com Thu Aug 14 18:23:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F1NDT7018790 for ; Thu, 14 Aug 2008 18:23:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F1N9Br028400 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Aug 2008 02:23:12 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5M00D03BULVH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:23:09 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M008Z0BULRTC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:23:09 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7F1N9GR015156 for ; Thu, 14 Aug 2008 18:23:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5M00401BPVT800@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:23:09 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5M00EN6BUHPED0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 14 Aug 2008 18:23:09 -0700 (PDT) Date: Thu, 14 Aug 2008 18:17:16 -0700 From: "Garrett D'Amore" Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: Sender: Garrett.Damore@sun.com To: Jan Pechanec Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <48A4D91C.1070701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> <48A4504B.9030401@sun.com> <48A452E5.5070303@Sun.COM> <48A46774.1030204@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1003 Jan Pechanec wrote: > On Thu, 14 Aug 2008, Jan Pechanec wrote: > > >>> Thank you for your clarifications, which were pretty much as I expected. My >>> only question relates to your answer to the question about key management... >>> are you saying you believe in the future you can add use of an alternate key >>> store using the OpenSSL library? (That seems moderately surprising to me. And >>> I recognize its "not this project".) >>> >> there is a patch to our PKCS#11 engine code that adds support for >> accessing RSA keys by reference (label). I think we need to contact OpenSSL >> team about extending the ENGINE API before we could start using it from >> other applications, and integrate that new engine code into Solaris. >> > > forgot to mention that there is also "6479874 OpenSSL should support > key by reference/hardware keystores" that discusses the issue. J. > > Thanks for the clarification. Yeah, it would be cool if OpenSSL could do this. -- Garrett From Jan.Pechanec@sun.com Tue Sep 9 12:36:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89Jap8i018637 for ; Tue, 9 Sep 2008 12:36:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m89JadZd020204 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 03:36:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Y00I0115EU800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 12:36:50 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Y00HJU15CZN10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 12:36:49 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89Jam5D008055 for ; Tue, 09 Sep 2008 19:36:48 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Y00J0110JEA00@fe-emea-09.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 20:36:48 +0100 (BST) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Y00DYX15BMGC0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 20:36:48 +0100 (BST) Date: Tue, 09 Sep 2008 21:35:57 +0200 (CEST) From: Jan Pechanec Subject: Re: SunSSH with the OpenSSL PKCS#11 engine support [PSARC/2008/520 Self Review] In-reply-to: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@fossa.czech.sun.com To: PSARC-ext@sun.com Cc: Darren.Moffat@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808141523.m7EFNbaW019456@sac.sfbay.sun.com> Status: RO Content-Length: 351 On Thu, 14 Aug 2008, Darren J Moffat wrote: > >Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >This information is Copyright 2008 Sun Microsystems >1. Introduction > 1.1. Project/Component Working Name: > > SunSSH with the OpenSSL PKCS#11 engine support one thing forgotten - we request micro/patch release binding. J. -- Jan Pechanec