From sacadmin Fri Aug 15 08:07:59 2008 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 m7FF7xBI006528; Fri, 15 Aug 2008 08:07:59 -0700 (PDT) Received: (from sommerfe@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7FF7xCZ006524; Fri, 15 Aug 2008 08:07:59 -0700 (PDT) Date: Fri, 15 Aug 2008 08:07:59 -0700 (PDT) From: William Sommerfeld Message-Id: <200808151507.m7FF7xCZ006524@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: paul.wernau@sun.com Subject: ikeadm token login [PSARC/2008/525 FastTrack timeout 08/22/2008] Status: RO Content-Length: 552 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: ikeadm token login 1.2. Name of Document Author/Supplier: Author: Paul Wernau 1.3 Date of This Document: 15 August, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sommerfeld@sun.com Fri Aug 15 08:11:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FFB7Yf006565 for ; Fri, 15 Aug 2008 08:11:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7FFB3Ix025534; Fri, 15 Aug 2008 08:11:06 -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 <0K5N00G1HE6HOU00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 08:11:05 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00GA1E6H0N30@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 08:11:05 -0700 (PDT) Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FFB4aI004557; Fri, 15 Aug 2008 11:11:04 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FFB3e0028157; Fri, 15 Aug 2008 11:11:03 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FFB3VP028156; Fri, 15 Aug 2008 11:11:03 -0400 (EDT) Date: Fri, 15 Aug 2008 11:11:02 -0400 From: Bill Sommerfeld Subject: 2008/525 ikeadm token login To: PSARC-ext Cc: Paul Wernau Message-id: <1218813062.6977.31.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 4559 I'm sponsoring this fasttrack for Paul Wernau. Timer expires on 8/22/2008. Release binding is Patch/Micro. The new ikeadm and ikecert subcommands, options, and associated behavior have a Committed stability level. Description: ------------ Private keys for IPsec/IKE are currently stored in the clear on disk or the pin for a PKCS#11 token is stored in the clear. What this effectively means is that anyone with root access to a system has access to use the private keys. In the case of someone without a PKCS#11 hardware token device, they can potentially clone the keys, either by taking the on-disk private key file directly or by copying the PKCS#11 softtoken keystore and noting the pin. If the pin were not stored in the clear on disk, the softtoken store would be mostly useless. Even in the case of a hardware keystore, root access to the system means immediate access to use the keys indirectly. Consumers in highly secure environments need the ability to be able to control use of keying material. Mobile users or users with smartcard devices, which store private keying material on the cards themselves, need the ability to be protected in the case of stolen device(s). Keeping the pin on disk with a smartcard also violates the "something you have, something you know" principle, as you don't need to know the pin. The reason that the pin is currently stored in the clear is that the in.iked service starts up on boot and needs the pin to access keying material. A similar bootstrapping problem has existed for some time with SSL on webservers. The service can't start until someone unlocks the key, which affects availability. It is up to the administrator of the webserver whether user invention is required by site policy. We intend to allow Solaris IPsec/IKE administrators the same choice. Proposal: --------- This project allows in.iked(1m) to start in a mode with PKCS#11 token store backed private keys initially locked, allowing the administrator to unlock them later on a running in.iked process. Administrators will have the ability to store the pin in the clear, but will default to being locked until opened. Additionally, an observability mechanism will be added to ikeadm(1m) to allow the user to observe the contents of the certificate cache and the status of the associated keys, if any. Details: -------- In the case that the pin is stored in the clear on disk, operations will continue as normal. In the case that pin is required, ikeadm(1m) will be extended to unlock the private key as follows: # ikeadm token login e.g. # ikeadm token login "Sun Metaslot" Enter PIN for PKCS#11 token: ikeadm: PKCS#11 operation successful ikeadm(1m) will be extended to dump the certificate cache so one can see the status. In the case of this object, we see the following on an unlocked token. # ikeadm dump certcache [SNIP] CERTIFICATE CACHE ID: 11 Subject Name: Issuer Name: [trusted certificate] [Private key available] To make the key inaccessible, ikeadm(1m) is extended to lock the PKCS#11 backed private key as follows: # ikeadm token logout e.g. # ikeadm token logout "Sun Metaslot" ikeadm: PKCS#11 operation successful The certcache subcommand will show the private key in a locked position, as follows, either before a login or after a logout. # ikeadm dump certcache CERTIFICATE CACHE ID: 11 Subject Name: Issuer Name: [trusted certificate] [Private key linked but locked] In the cases of login and logout, the operation is applied to all objects on the PKCS#11 token, as the PKCS#11 spec has users unlock the token itself, not individual objects. ikecert(1m) will be changed so that the pin is not stored in the clear on disk unless the -p option is given. e.g. This syntax does not store the pin in the clear. # ikecert certlocal -ks -t rsa-sha1 -m 1024 -T "Sun Metaslot" \ -D "CN=pinnotinclear, O=Sun, C=US" Creating private key. Enter PIN for PKCS#11 token: This syntax would be: # ikecert certlocal -ks -t rsa-sha1 -m 1024 -T "Sun Metaslot" \ -p -D "CN=pininclear, O=Sun, C=US" Creating private key. Enter PIN for PKCS#11 token: The existing -U (unlink) and -L (link) options, combined with or without the existence of -p can be use to migrate from one format to another. From Darren.Moffat@Sun.COM Fri Aug 15 08:23:11 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 m7FFNAtI006713 for ; Fri, 15 Aug 2008 08:23:11 -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 m7FFN8pS010944; Fri, 15 Aug 2008 16:23:09 +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 <0K5N00417EQLB200@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 09:23:09 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00LUOEQK3G50@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 09:23:09 -0600 (MDT) 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 m7FFN8kI010485; Fri, 15 Aug 2008 15:23: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 <0K5N00601EQ19S00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 15 Aug 2008 16:23: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 <0K5N00599EQETH40@fe-emea-09.sun.com>; Fri, 15 Aug 2008 16:23:02 +0100 (BST) Date: Fri, 15 Aug 2008 16:23:01 +0100 From: Darren J Moffat Subject: Re: 2008/525 ikeadm token login In-reply-to: <1218813062.6977.31.camel@localhost> Sender: Darren.Moffat@Sun.COM To: Bill Sommerfeld Cc: PSARC-ext , Paul Wernau Message-id: <48A59F55.60807@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: <1218813062.6977.31.camel@localhost> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 411 Can any user run 'ikeadm token login' ? Or is a specific authorisation needed ? If so what is it ? Same for logout. I'm particularly interested in the case where the key is actually a users smartcard and the user has no direct root access. In this case I would rather not give them an RBAC profile that allows running ikeadm as uid=0 because then they can do other things to ike. -- Darren J Moffat From Paul.Wernau@sun.com Fri Aug 15 08:38:31 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 m7FFcUSf006883 for ; Fri, 15 Aug 2008 08:38:30 -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 m7FFcQ80049153; Fri, 15 Aug 2008 09:38:30 -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 <0K5N00K1ZFG6G400@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 08:38:30 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00JVIFG5OZ10@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 08:38:29 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7FFcTPI009246; Fri, 15 Aug 2008 15:38:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5N00F01DP4Q300@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM); Fri, 15 Aug 2008 09:38:29 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5N00AM1FFRCKD0@mail-amer.sun.com>; Fri, 15 Aug 2008 09:38:16 -0600 (MDT) Date: Fri, 15 Aug 2008 11:38:08 -0400 From: Paul Wernau Subject: Re: 2008/525 ikeadm token login In-reply-to: <48A59F55.60807@Sun.COM> Sender: Paul.Wernau@sun.com To: Darren J Moffat Cc: Bill Sommerfeld , PSARC-ext Message-id: <48A5A2E0.3050700@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: <1218813062.6977.31.camel@localhost> <48A59F55.60807@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1104 Darren J Moffat wrote: > Can any user run 'ikeadm token login' ? Or is a specific authorisation > needed ? If so what is it ? Same for logout. > The exisiting model for ikeadm in general is that a user needs to have root privileges. A non-root user will get a permissions error attempting to open the door to in.iked: pwernau@host$ ikeadm dump p1 Unable to communicate with in.iked ikeadm: open_door failed: No such file or directory ikeadm: Fatal error - exiting. > I'm particularly interested in the case where the key is actually a > users smartcard and the user has no direct root access. In this case I > would rather not give them an RBAC profile that allows running ikeadm as > uid=0 because then they can do other things to ike. You bring up an good point. Is there some pre-existing authorization you'd recommend? I see solaris.device.grant (Delegate Device Administration) as a potential. Or we could create a new set. I agree with you that it is worth extending the ikeadm <-> in.iked interface to be authorization aware for this particular subcommand. Thanks, Paul From Darren.Moffat@sun.com Fri Aug 15 09:05:53 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 m7FG5rXe007743 for ; Fri, 15 Aug 2008 09:05:53 -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 m7FG5p6O024869; Fri, 15 Aug 2008 09:05:52 -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 <0K5N00M1BGPRLC00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 09:05:51 -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 <0K5N00J6AGPP8C40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 09:05:50 -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-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7FG5nx1010687; Fri, 15 Aug 2008 16:05:49 +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 <0K5N00001GM5BX00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 15 Aug 2008 17:05:49 +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 <0K5N0054GGPOTH50@fe-emea-09.sun.com>; Fri, 15 Aug 2008 17:05:49 +0100 (BST) Date: Fri, 15 Aug 2008 17:05:48 +0100 From: Darren J Moffat Subject: Re: 2008/525 ikeadm token login In-reply-to: <48A5A2E0.3050700@sun.com> Sender: Darren.Moffat@sun.com To: Paul Wernau Cc: Bill Sommerfeld , PSARC-ext Message-id: <48A5A95C.2060601@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: <1218813062.6977.31.camel@localhost> <48A59F55.60807@Sun.COM> <48A5A2E0.3050700@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 744 Paul Wernau wrote: > You bring up an good point. Is there some pre-existing authorization > you'd recommend? I see solaris.device.grant (Delegate Device > Administration) as a potential. Or we could create a new set. I don't think that one is appropriate. I would expect a completely new authorization under solaris.network. The closest existing one for this is solaris.network.wifi.wep. My suggestion would be: solaris.network.ipsec.ike.token.login solaris.network.ipsec.ike.token.logout This means you can give out solaris.network.* or solaris.network.ipsec.*, or be very specific and allow login but not logout. It also leaves you "space" in the hierarchy to do other delegated admin on ike and ipsec. -- Darren J Moffat From Paul.Wernau@sun.com Fri Aug 15 09:06:54 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 m7FG6rNt007778 for ; Fri, 15 Aug 2008 09:06:53 -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 m7FG6r4N025219; Fri, 15 Aug 2008 09:06:53 -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 <0K5N00L0JGRGDM00@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 09:06:52 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00J7HGREP340@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 09:06:50 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7FG6oxD029295; Fri, 15 Aug 2008 16:06:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5N00701GDLCN00@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM); Fri, 15 Aug 2008 10:06:50 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5N00D12GR70ZB0@mail-amer.sun.com>; Fri, 15 Aug 2008 10:06:44 -0600 (MDT) Date: Fri, 15 Aug 2008 12:06:36 -0400 From: Paul Wernau Subject: Re: 2008/525 ikeadm token login In-reply-to: <48A5A95C.2060601@Sun.COM> Sender: Paul.Wernau@sun.com To: Darren J Moffat Cc: Bill Sommerfeld , PSARC-ext Message-id: <48A5A98C.2040600@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: <1218813062.6977.31.camel@localhost> <48A59F55.60807@Sun.COM> <48A5A2E0.3050700@sun.com> <48A5A95C.2060601@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 855 Darren J Moffat wrote: > Paul Wernau wrote: >> You bring up an good point. Is there some pre-existing authorization >> you'd recommend? I see solaris.device.grant (Delegate Device >> Administration) as a potential. Or we could create a new set. > > I don't think that one is appropriate. I would expect a completely new > authorization under solaris.network. The closest existing one for this > is solaris.network.wifi.wep. My suggestion would be: > > solaris.network.ipsec.ike.token.login > solaris.network.ipsec.ike.token.logout > > This means you can give out solaris.network.* or > solaris.network.ipsec.*, or be very specific and allow login but not > logout. > > It also leaves you "space" in the hierarchy to do other delegated admin > on ike and ipsec. > OK, that sounds reasonable and is completely fine by me. -Paul From carlsonj@phorcys.east.sun.com Fri Aug 15 09:51:41 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 m7FGpeQb009059 for ; Fri, 15 Aug 2008 09:51:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7FGpcnh009298; Fri, 15 Aug 2008 10:51:39 -0600 (MDT) 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 <0K5N0040ZIU28D00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 09:51:38 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00JD6IU18DB0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 09:51:37 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FGpbre010719; Fri, 15 Aug 2008 12:51:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FGpb4T010716; Fri, 15 Aug 2008 12:51:37 -0400 (EDT) Date: Fri, 15 Aug 2008 12:51:37 -0400 From: James Carlson Subject: Re: 2008/525 ikeadm token login In-reply-to: <1218813062.6977.31.camel@localhost> To: Bill Sommerfeld Cc: PSARC-ext , Paul Wernau Message-id: <18597.46105.179275.513035@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218813062.6977.31.camel@localhost> Status: RO Content-Length: 770 Bill Sommerfeld writes: > I'm sponsoring this fasttrack for Paul Wernau. Timer expires on > 8/22/2008. Release binding is Patch/Micro. The new ikeadm and ikecert > subcommands, options, and associated behavior have a Committed stability > level. [...] > ikecert(1m) will be changed so that the pin is not stored in the clear > on disk unless the -p option is given. Isn't this (changing the default way the pin is stored) an incompatible change? That seems like a reasonable and good change for Minor or higher, but why do this in a patch? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Paul.Wernau@sun.com Fri Aug 15 10:01:23 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 m7FH1Nfg010429 for ; Fri, 15 Aug 2008 10:01:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7FH1MXE012185; Fri, 15 Aug 2008 11:01:23 -0600 (MDT) 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 <0K5N00B0DJAAEA00@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 11:01:22 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00L3AJA93GB0@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 11:01:21 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7FH1LSp009675; Fri, 15 Aug 2008 17:01:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5N00101JA6CM00@mail-amer.sun.com> (original mail from Paul.Wernau@Sun.COM); Fri, 15 Aug 2008 11:01:21 -0600 (MDT) Received: from [129.148.174.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5N00B77JA8D140@mail-amer.sun.com>; Fri, 15 Aug 2008 11:01:21 -0600 (MDT) Date: Fri, 15 Aug 2008 13:01:13 -0400 From: Paul Wernau Subject: Re: 2008/525 ikeadm token login In-reply-to: <18597.46105.179275.513035@gargle.gargle.HOWL> Sender: Paul.Wernau@sun.com To: James Carlson Cc: Bill Sommerfeld , PSARC-ext Message-id: <48A5B659.4080500@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: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 955 James Carlson wrote: > Bill Sommerfeld writes: >> I'm sponsoring this fasttrack for Paul Wernau. Timer expires on >> 8/22/2008. Release binding is Patch/Micro. The new ikeadm and ikecert >> subcommands, options, and associated behavior have a Committed stability >> level. > [...] >> ikecert(1m) will be changed so that the pin is not stored in the clear >> on disk unless the -p option is given. > > Isn't this (changing the default way the pin is stored) an > incompatible change? > > That seems like a reasonable and good change for Minor or higher, but > why do this in a patch? > Hmmm, I had queried the IPsec team about the very same question and we had decided collectively that this is probably an exceptional case (if the feature existed before, it would have been done that way.) I actually would like Bill Sommerfeld or Dan McDonald to weigh in with their opinion as I am kind of on the fence about this particular issue. -Paul From danmcd@sun.com Fri Aug 15 10:25:26 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 m7FHPPiw011124 for ; Fri, 15 Aug 2008 10:25:25 -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 m7FHPMos029624; Fri, 15 Aug 2008 18:25:23 +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 <0K5N00105KEAPI00@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 10:25:22 -0700 (PDT) Received: from everywhere.east.sun.com ([129.148.19.2]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00JITKE8OVC0@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 10:25:21 -0700 (PDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FHPJ3j019245; Fri, 15 Aug 2008 13:25:19 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FHPJ3q019244; Fri, 15 Aug 2008 13:25:19 -0400 (EDT) Date: Fri, 15 Aug 2008 13:25:19 -0400 From: Dan McDonald Subject: Re: 2008/525 ikeadm token login In-reply-to: <48A5B659.4080500@sun.com> To: Paul Wernau Cc: James Carlson , Bill Sommerfeld , PSARC-ext Message-id: <20080815172519.GC18920@sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security 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: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> <48A5B659.4080500@sun.com> X-Authentication-warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1182 On Fri, Aug 15, 2008 at 01:01:13PM -0400, Paul Wernau wrote: >> Isn't this (changing the default way the pin is stored) an >> incompatible change? The storage of the PIN isn't an interface, per se. You are worried, I suspect, about least-surprise if someone creates a new keypair and subsequently has to "ikeadm setpin" every time in.iked restarts. There will be no surprise to admins who had created a keypair prior to this change. >> That seems like a reasonable and good change for Minor or higher, but >> why do this in a patch? The (vastly) increased security benefit (no on-disk clear private keys) is the prime mover for this RFE (and ARC case). > Hmmm, I had queried the IPsec team about the very same question and we had > decided collectively that this is probably an exceptional case (if the > feature existed before, it would have been done that way.) I actually > would like Bill Sommerfeld or Dan McDonald to weigh in with their opinion > as I am kind of on the fence about this particular issue. We feel that the increase in security (and for a feature traditionally used only with hardware keystores) outweighs the detriment of any disruptive changes. Dan From carlsonj@phorcys.east.sun.com Fri Aug 15 10:45:51 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 m7FHjpow011692 for ; Fri, 15 Aug 2008 10:45:51 -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 m7FHjogr025794; Fri, 15 Aug 2008 10:45:50 -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 <0K5N0020NLCDM200@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 10:45:49 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00JN4LCBP1A0@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 10:45:48 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FHjlIW011076; Fri, 15 Aug 2008 13:45:47 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FHjlYq011073; Fri, 15 Aug 2008 13:45:47 -0400 (EDT) Date: Fri, 15 Aug 2008 13:45:47 -0400 From: James Carlson Subject: Re: 2008/525 ikeadm token login In-reply-to: <20080815172519.GC18920@sun.com> To: Dan McDonald Cc: Paul Wernau , Bill Sommerfeld , PSARC-ext Message-id: <18597.49355.224573.219795@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> <48A5B659.4080500@sun.com> <20080815172519.GC18920@sun.com> Status: RO Content-Length: 1977 Dan McDonald writes: > On Fri, Aug 15, 2008 at 01:01:13PM -0400, Paul Wernau wrote: > >> Isn't this (changing the default way the pin is stored) an > >> incompatible change? > > The storage of the PIN isn't an interface, per se. > > You are worried, I suspect, about least-surprise if someone creates a new > keypair and subsequently has to "ikeadm setpin" every time in.iked restarts. Exactly. "It didn't used to do that before." > > Hmmm, I had queried the IPsec team about the very same question and we had > > decided collectively that this is probably an exceptional case (if the > > feature existed before, it would have been done that way.) I actually > > would like Bill Sommerfeld or Dan McDonald to weigh in with their opinion > > as I am kind of on the fence about this particular issue. > > We feel that the increase in security (and for a feature traditionally used > only with hardware keystores) outweighs the detriment of any disruptive > changes. Yep, I understand the motivation. This should _at least_ have a patch README entry and a release note for the update it goes into, and should probably get other exposure as well. The fact that nobody will be able to provide a clear set of "how to use this stuff" directions should give the project team some pause about tightening security in this way. A recipe would have to say something like this in the middle: "If you are running Solaris 10 and have patch 999998-01 [SPARC] or 999999-01 [x86] installed, then you need to include '-p' on the following command line, so that the unattended service will start up correctly at boot time. If you don't have that patch installed, then '-p' isn't recognized, and unattended operation will be the default ...." Poor user. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From danmcd@sun.com Fri Aug 15 10:52: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 m7FHqSag012439 for ; Fri, 15 Aug 2008 10:52: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 m7FHqOv5028070; Fri, 15 Aug 2008 11:52:27 -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 <0K5N0020NLNEVJ00@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 10:52:26 -0700 (PDT) Received: from everywhere.east.sun.com ([129.148.19.2]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00J6BLNDP3D0@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 10:52:26 -0700 (PDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FHqPsP019296; Fri, 15 Aug 2008 13:52:25 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FHqOZv019295; Fri, 15 Aug 2008 13:52:24 -0400 (EDT) Date: Fri, 15 Aug 2008 13:52:24 -0400 From: Dan McDonald Subject: Re: 2008/525 ikeadm token login In-reply-to: <18597.49355.224573.219795@gargle.gargle.HOWL> To: James Carlson Cc: Dan McDonald , Paul Wernau , Bill Sommerfeld , PSARC-ext Message-id: <20080815175224.GE18920@sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security 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: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> <48A5B659.4080500@sun.com> <20080815172519.GC18920@sun.com> <18597.49355.224573.219795@gargle.gargle.HOWL> X-Authentication-warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1202 On Fri, Aug 15, 2008 at 01:45:47PM -0400, James Carlson wrote: > The fact that nobody will be able to provide a clear set of "how to > use this stuff" directions should give the project team some pause > about tightening security in this way. A recipe would have to say > something like this in the middle: > > "If you are running Solaris 10 and have patch 999998-01 > [SPARC] or 999999-01 [x86] installed, then you need to include > '-p' on the following command line, so that the unattended > service will start up correctly at boot time. If you don't > have that patch installed, then '-p' isn't recognized, and > unattended operation will be the default ...." > > Poor user. The frequency of new-key generation (typically measured in once-per-N-years, for 1 <= N <= 4) is such that the above paragraph will not apply often. Maybe that's why you're worried --> it's so infrequent that people will not think to look at the release notes. I guess the big question for patch-binding is whether or not customers are going to be banging down our door for this added security. Perhaps a ping to some sun-internal customer-contacting aliases (you know the ones I mean) would be in order? Dan From carlsonj@phorcys.east.sun.com Fri Aug 15 11:03:02 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 m7FI31Nr014326 for ; Fri, 15 Aug 2008 11:03:02 -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 m7FI2vSJ001248; Sat, 16 Aug 2008 02:02:58 +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 <0K5N00307M4WA900@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 11:02:56 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00JZJM4VP1C0@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 11:02:56 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FI2twP011208; Fri, 15 Aug 2008 14:02:55 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FI2tep011205; Fri, 15 Aug 2008 14:02:55 -0400 (EDT) Date: Fri, 15 Aug 2008 14:02:55 -0400 From: James Carlson Subject: Re: 2008/525 ikeadm token login In-reply-to: <20080815175224.GE18920@sun.com> To: Dan McDonald Cc: PSARC-ext , Bill Sommerfeld , Paul Wernau Message-id: <18597.50383.621495.259711@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> <48A5B659.4080500@sun.com> <20080815172519.GC18920@sun.com> <18597.49355.224573.219795@gargle.gargle.HOWL> <20080815175224.GE18920@sun.com> Status: RO Content-Length: 1111 Dan McDonald writes: > The frequency of new-key generation (typically measured in once-per-N-years, > for 1 <= N <= 4) is such that the above paragraph will not apply often. > Maybe that's why you're worried --> it's so infrequent that people will not > think to look at the release notes. More likely, they're going to go looking for a blog entry with a "recipe" in it. > I guess the big question for patch-binding is whether or not customers are > going to be banging down our door for this added security. Perhaps a ping to > some sun-internal customer-contacting aliases (you know the ones I mean) > would be in order? That wouldn't be a bad idea. I suppose that if the number of folks who've set a pin at all is vanishingly small, and thus the number who'd retain any memory of how it once functioned is also low, then changing how it functions by default is no great problem. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Fri Aug 15 12:16:08 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 m7FJG8gU022755 for ; Fri, 15 Aug 2008 12:16:08 -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 m7FJG5vJ022301; Fri, 15 Aug 2008 12:16:07 -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 <0K5N00K0LPIT0100@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 12:16:05 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N006H3PIRV280@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 12:16:03 -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 m7FJG32H018628; Fri, 15 Aug 2008 14:16:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7FJG2Xb018627; Fri, 15 Aug 2008 14:16:03 -0500 (CDT) Date: Fri, 15 Aug 2008 14:16:02 -0500 From: Nicolas Williams Subject: Re: 2008/525 ikeadm token login In-reply-to: <18597.49355.224573.219795@gargle.gargle.HOWL> To: James Carlson Cc: Dan McDonald , Paul Wernau , Bill Sommerfeld , PSARC-ext Mail-followup-to: James Carlson , Dan McDonald , Paul Wernau , Bill Sommerfeld , PSARC-ext Message-id: <20080815191602.GT17511@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: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> <48A5B659.4080500@sun.com> <20080815172519.GC18920@sun.com> <18597.49355.224573.219795@gargle.gargle.HOWL> 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: 453 On Fri, Aug 15, 2008 at 01:45:47PM -0400, James Carlson wrote: > Yep, I understand the motivation. > > This should _at least_ have a patch README entry and a release note > for the update it goes into, and should probably get other exposure as > well. > > [...] > > Poor user. I'd rather that ikecert have two new, mutually exclusive options, rather than one, and that it warn if neither is provided, with the default behavior left as is. Nico -- From carlsonj@phorcys.east.sun.com Fri Aug 15 12:21:49 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 m7FJLm20023141 for ; Fri, 15 Aug 2008 12:21:49 -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 m7FJLdn2014006; Fri, 15 Aug 2008 20:21:46 +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 <0K5N00K01PS7MT00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 12:21:43 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N006SZPS7V280@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 12:21:43 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FJLg1O011813; Fri, 15 Aug 2008 15:21:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FJLgYF011810; Fri, 15 Aug 2008 15:21:42 -0400 (EDT) Date: Fri, 15 Aug 2008 15:21:42 -0400 From: James Carlson Subject: Re: 2008/525 ikeadm token login In-reply-to: <20080815191602.GT17511@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Paul Wernau , Bill Sommerfeld , PSARC-ext Message-id: <18597.55110.468522.387978@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218813062.6977.31.camel@localhost> <18597.46105.179275.513035@gargle.gargle.HOWL> <48A5B659.4080500@sun.com> <20080815172519.GC18920@sun.com> <18597.49355.224573.219795@gargle.gargle.HOWL> <20080815191602.GT17511@Sun.COM> Status: RO Content-Length: 703 Nicolas Williams writes: > I'd rather that ikecert have two new, mutually exclusive options, rather > than one, and that it warn if neither is provided, with the default > behavior left as is. That'd be the clear alternative, but rather than force the project team to chew up an option flag, I'd like to know if anyone _really_ cares. If there are no real users of the 'pin' magic (and I think it's possible that there aren't), then changing the default now would be goodness. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Tue Aug 26 15:49:02 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 m7QMn1Ah014966 for ; Tue, 26 Aug 2008 15:49:02 -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 m7QMmrQr018193; Tue, 26 Aug 2008 23:49:00 +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 <0K6800B05CPNCD00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 15:48:59 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K680044VCPM4SB0@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 15:48:59 -0700 (PDT) Received: from localhost.SFBay.Sun.COM (dhcp-umpk17-109-36.SFBay.Sun.COM [129.146.109.36]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QMmvjI045185; Tue, 26 Aug 2008 18:48:57 -0400 (EDT) Received: from localhost.SFBay.Sun.COM (localhost [127.0.0.1]) by localhost.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m7QMmusx009761; Tue, 26 Aug 2008 15:48:56 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m7QMmuAj009760; Tue, 26 Aug 2008 15:48:56 -0700 (PDT) Date: Tue, 26 Aug 2008 15:48:55 -0700 From: Bill Sommerfeld Subject: Re: 2008/525 ikeadm token login In-reply-to: <1218813062.6977.31.camel@localhost> To: PSARC-ext Cc: Paul Wernau Message-id: <1219790935.1822.22.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218813062.6977.31.camel@localhost> X-Authentication-warning: localhost.SFBay.Sun.COM: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 139 According to the minutes of the meeting of 8/20/2008, PSARC approved this fast-track last Wednesday. I've marked the case accordingly.