From wyllys@borg.sfbay.sun.com Mon Oct 15 10:52:38 2007 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 l9FHqbMC007858 for ; Mon, 15 Oct 2007 10:52:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FHmwCv008387 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Tue, 16 Oct 2007 01:49:15 +0800 (SGT) 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 <0JPY00M3FS5Z2800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Mon, 15 Oct 2007 10:49:11 -0700 (PDT) Received: from borg.SFBay.Sun.COM ([10.6.50.138]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00LW2S5Z1700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Mon, 15 Oct 2007 10:49:11 -0700 (PDT) Received: from borg.SFBay.Sun.COM (localhost [127.0.0.1]) by borg.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9FHielh015959; Mon, 15 Oct 2007 10:44:40 -0700 (PDT) Received: (from wyllys@localhost) by borg.SFBay.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9FHietA015955; Mon, 15 Oct 2007 10:44:40 -0700 (PDT) Date: Mon, 15 Oct 2007 10:44:40 -0700 (PDT) From: Wyllys Ingersoll Subject: Kerberos NULL replay cache [PSARC/2007/597 FastTrack timeout 10/22/2007] To: PSARC-ext@sun.com Cc: kerberos-discuss@opensolaris.org Message-id: <200710151744.l9FHietA015955@borg.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1712 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Kerberos NULL replay cache 1.2. Name of Document Author/Supplier: Author: Peter Shoults 1.3 Date of This Document: 15 October, 2007 4. Technical Description Name: Kerberos NULL Replay Cache Submitter: Peter Shoults Sponsor: Wyllys Ingersoll Release Taxonomy: Micro/Patch Interface Taxonomy: Unstable Description: Customers are asking for the functionality that currently exists in the MIT kerberos code that allows for one to run kerberos and have the replay cache functionality disabled. Currently that is not possible, the only two choices being files (default) or memory. The current interface for specifying the type of replay cache is thru the krb5envvar environment variable KRB5RCNAME. For example, to set it to "memory" cache: $ export KRB5RCNAME=MEMORY This fix will allow for the parameter of NONE. The vectored routines (*rc_none*) simply would return without executing any code. Man Page Diffs for krb5envvar(5): 112c112 < where can be either FILE or MEMORY. where can be either FILE, MEMORY or NONE. When specifying the NONE replay cache time you need to > understand that this will disable the replay cache, and > all security risks that this would present. This would > include all the risks outlined above. 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 Darren.Moffat@sun.com Mon Oct 15 13:20:14 2007 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 l9FKKD87012106 for ; Mon, 15 Oct 2007 13:20:14 -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 l9FKGo3v013547 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 04:16:52 +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 <0JPY00I09Z01JR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 14:16:50 -0600 (MDT) Received: from gmp-eb-mail-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 <0JPY00DZIZ00MX80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 14:16:49 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9FKGmU3007659 for ; Mon, 15 Oct 2007 20:16:48 +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 <0JPY00101YUPIT00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 21:16:48 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPY00M0WYZZ9P30@fe-emea-10.sun.com>; Mon, 15 Oct 2007 21:16:47 +0100 (BST) Date: Mon, 15 Oct 2007 21:16:47 +0100 From: Darren J Moffat Subject: Re: Kerberos NULL replay cache [PSARC/2007/597 FastTrack timeout 10/22/2007] In-reply-to: <200710151744.l9FHietA015955@borg.SFBay.Sun.COM> Sender: Darren.Moffat@sun.com To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4713CAAF.4000004@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710151744.l9FHietA015955@borg.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 563 Wyllys Ingersoll wrote: > Customers are asking for the functionality that currently exists in the MIT > kerberos code that allows for one to run kerberos and have the replay cache > functionality disabled. Currently that is not possible, the only two choices Why do they want that functionality ? What is wrong with the reply cache that means they desire to disable it and take the security risks associated with doing so ? I want to work out if disabling this is actually fixing the real problem or just masking some other issue. -- Darren J Moffat From Nicolas.Williams@sun.com Mon Oct 15 13:40:12 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FKeCAB013661 for ; Mon, 15 Oct 2007 13:40:12 -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 l9FKanll023679; Mon, 15 Oct 2007 13:36: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 <0JPY00A05ZXCBN00@nwk-avmta-2.sfbay.sun.com>; Mon, 15 Oct 2007 13:36:48 -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 <0JPY00A28ZXBA000@nwk-avmta-2.sfbay.sun.com>; Mon, 15 Oct 2007 13:36:48 -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 l9FKakZw000566; Mon, 15 Oct 2007 15:36:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9FKakgl000565; Mon, 15 Oct 2007 15:36:46 -0500 (CDT) Date: Mon, 15 Oct 2007 15:36:46 -0500 From: Nicolas Williams Subject: Re: Kerberos NULL replay cache [PSARC/2007/597 FastTrack timeout 10/22/2007] In-reply-to: <4713CAAF.4000004@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <20071015203646.GY29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710151744.l9FHietA015955@borg.SFBay.Sun.COM> <4713CAAF.4000004@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: 2137 On Mon, Oct 15, 2007 at 09:16:47PM +0100, Darren J Moffat wrote: > Wyllys Ingersoll wrote: > > Customers are asking for the functionality that currently exists in the MIT > > kerberos code that allows for one to run kerberos and have the replay cache > > functionality disabled. Currently that is not possible, the only two choices > > Why do they want that functionality ? > > What is wrong with the reply cache that means they desire to disable it > and take the security risks associated with doing so ? Latency. We already have a MEMORY rcache, and a way to put the normal FILE rcache on tmpfs (/var/run/...). So latency already is, or _should be_ quite low. Have we got any profile data showing what is the latency of each of the various rcache options we have now? Note that Kerberos V security depends on replays being detected (either because they are outside the allowed time skew window or because they are detected by the replay cache). A a null rcache option would have to be used with great care. I would hate for an insecure configuration to become very common if we could instead squeeze the rcache latency down further. Note: The Solaris krb5 team already has squeezed quite a bit out of the MIT FILE rcache turning various functions into macros and factoring expensive system calls out of the main loop, but the limiting factor on anything other than tmpfs is fsync(), and therefore, I/O latencies. But the MEMORY rcache and the FILE rcache on tmpfs ought to perform well enough already for any and all customers. That MIT supports a NONE rcache should be no excuse for Solaris supporting it too if any of the other options performs sufficiently well. Solaris Kerberos can be better than MIT krb5, and that can be a differentiator for us, even if we'll eventually contribute our changes back to MIT (technically MIT could pick them up now, if they weren't CDDL-averse...). > I want to work out if disabling this is actually fixing the real problem > or just masking some other issue. Profile data (obtainable with dtrace, no doubt) would help. Nico -- From sommerfeld@sun.com Mon Oct 15 13:53:50 2007 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 l9FKrnmG014169 for ; Mon, 15 Oct 2007 13:53:49 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FKoCf0007754; Mon, 15 Oct 2007 21:50:27 +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 <0JPZ00K1B0K1VF00@brm-avmta-1.central.sun.com>; Mon, 15 Oct 2007 14:50:25 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPZ00KOO0JZ2A00@brm-avmta-1.central.sun.com>; Mon, 15 Oct 2007 14:50:23 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9FKoKMh046498; Mon, 15 Oct 2007 16:50:20 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9FKoKO5008775; Mon, 15 Oct 2007 16:50:20 -0400 (EDT) Date: Mon, 15 Oct 2007 16:50:19 -0400 From: Bill Sommerfeld Subject: Re: Kerberos NULL replay cache [PSARC/2007/597 FastTrack timeout 10/22/2007] In-reply-to: <20071015203646.GY29257@Sun.COM> To: Nicolas Williams Cc: Darren J Moffat , PSARC-ext@sun.com, Wyllys Ingersoll , kerberos-discuss@opensolaris.org Message-id: <1192481419.6747.60.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710151744.l9FHietA015955@borg.SFBay.Sun.COM> <4713CAAF.4000004@Sun.COM> <20071015203646.GY29257@Sun.COM> Status: RO Content-Length: 548 On Mon, 2007-10-15 at 15:36 -0500, Nicolas Williams wrote: > That MIT supports a NONE rcache should be no excuse for Solaris > supporting it too if any of the other options performs sufficiently > well. It's been a while since I glued kerberos into a protocol, but my recollection is that it is possible to do so (by including nonces or channel-binding-like things into the authenticator) in a way that renders the replay cache unnecessary. Any work done to manage a replay cache for such an application would be 100% wasted. - Bill From Nicolas.Williams@sun.com Mon Oct 15 14:12:39 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FLCdT1015169 for ; Mon, 15 Oct 2007 14:12:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FL9E0b019590; Mon, 15 Oct 2007 14:09:17 -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 <0JPZ00B1H1FGGX00@nwk-avmta-2.sfbay.sun.com>; Mon, 15 Oct 2007 14:09:16 -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 <0JPZ00A2S1FGO210@nwk-avmta-2.sfbay.sun.com>; Mon, 15 Oct 2007 14:09:16 -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 l9FL9Enl000616; Mon, 15 Oct 2007 16:09:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9FL9Eul000615; Mon, 15 Oct 2007 16:09:14 -0500 (CDT) Date: Mon, 15 Oct 2007 16:09:14 -0500 From: Nicolas Williams Subject: Re: Kerberos NULL replay cache [PSARC/2007/597 FastTrack timeout 10/22/2007] In-reply-to: <1192481419.6747.60.camel@thunk> To: Bill Sommerfeld Cc: Darren J Moffat , PSARC-ext@sun.com, Wyllys Ingersoll , kerberos-discuss@opensolaris.org Mail-followup-to: Bill Sommerfeld , Darren J Moffat , PSARC-ext@sun.com, Wyllys Ingersoll , kerberos-discuss@opensolaris.org Message-id: <20071015210914.GC29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710151744.l9FHietA015955@borg.SFBay.Sun.COM> <4713CAAF.4000004@Sun.COM> <20071015203646.GY29257@Sun.COM> <1192481419.6747.60.camel@thunk> 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: 1384 On Mon, Oct 15, 2007 at 04:50:19PM -0400, Bill Sommerfeld wrote: > On Mon, 2007-10-15 at 15:36 -0500, Nicolas Williams wrote: > > That MIT supports a NONE rcache should be no excuse for Solaris > > supporting it too if any of the other options performs sufficiently > > well. > > It's been a while since I glued kerberos into a protocol, but my > recollection is that it is possible to do so (by including nonces or > channel-binding-like things into the authenticator) in a way that > renders the replay cache unnecessary. Any work done to manage a replay > cache for such an application would be 100% wasted. Indeed it is, but not in the case of applications like TELNET, BSD r-cmd, FTP, or HTTP/Negotiate (although in the last protocol's case the situation is already compromised in other ways, such as by not providing mutual authentication nor any channel binding to TLS). The best example of an application that doesn't need an rcache is SSHv2, but because it shares a principal (host/...) with telnet and the others, it's still possible to attempt an MITM attack on SSHv2 (which will fail) and then re-use the AP-REQ from the SSHv2 client against telnet/... servers on the same target server. NFS w/ RPCSEC_GSS doesn't need an rcache either, provided that the "context handle" numbers assigned by the server in RPCSEC_GSS are always monotonically increasing. Nico --