[dhcwg] Re: Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt
Ken Raeburn <raeburn@mit.edu> Mon, 24 February 2003 20:14 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25128 for <dhcwg-archive@odin.ietf.org>; Mon, 24 Feb 2003 15:14:09 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OKMnU20656 for dhcwg-archive@odin.ietf.org; Mon, 24 Feb 2003 15:22:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKMnp20653 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 24 Feb 2003 15:22:49 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25098 for <dhcwg-web-archive@ietf.org>; Mon, 24 Feb 2003 15:13:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKLDp20582; Mon, 24 Feb 2003 15:21:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OK5lp19082 for <dhcwg@optimus.ietf.org>; Mon, 24 Feb 2003 15:05:47 -0500
Received: from raeburn.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24392 for <dhcwg@ietf.org>; Mon, 24 Feb 2003 14:56:35 -0500 (EST)
Received: from kal-el.raeburn.org (mail@kal-el.raeburn.org [18.101.0.230]) by raeburn.org (8.11.3/8.11.3) with ESMTP id h1OK0Sh08639; Mon, 24 Feb 2003 15:00:28 -0500 (EST)
Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 18nOm3-0003vE-00; Mon, 24 Feb 2003 15:00:27 -0500
From: Ken Raeburn <raeburn@mit.edu>
To: dhcwg@ietf.org
References: <87heaxpclz.fsf@luminous.mit.edu>
Date: Mon, 24 Feb 2003 15:00:27 -0500
In-Reply-To: <87heaxpclz.fsf@luminous.mit.edu> (Sam Hartman's message of "Fri, 21 Feb 2003 16:06:48 -0500")
Message-ID: <tx1lm05sb38.fsf@raeburn.org>
Lines: 91
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.50 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [dhcwg] Re: Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sam Hartman <hartmans@mit.edu> writes: > Hi. I'm not subscribed to the list, so please copy me on responses. > I'm sending these comments because a review of the option from a > Kerberos viewpoint was requested. Same here.... > The rationale for this draft claims that it will be used among other > reasons to cancel subscriber service. The presence of a Kerberos > ticket should not be used to imply authorization to use a service; > this is incompatible both with RFC 1510 and with current Kerberos > drafts. Even if the authorization data field is used to convey > authorization along with authentication, service tickets with should > not be issued with lifetimes longer than are acceptable. I.E. you > should only issue a ticket with a lifetime as long as you are willing > to have authorization cached. Agreed. The security model should not rely on the CCD behaving itself nicely. Even if you want long-lived tickets, presumably to reduce the frequency with which public-key PKINIT operations need to be done, and if you want them to carry authorization data, you could use renewable tickets or server-based hot-lists to close out a customer's access fairly quickly. Renewable tickets require repeated communication with the KDC to get new valid tickets with later expiration times, but they don't require the same public-key operations, and thus should be cheaper in CPU time. > The option if it exists should serve to invalidate caches to > deal with operational problems such as emergency rekeying of services > or testing, These do seem like valid reasons. > and the only effect of failing to honor this option should > be a temporary loss of service. If the issue is that the old service key has been exposed, failing to honor this option could result in transmitting arbitrary data "securely" to an intruder, or in a way that an intruder may be able to read it. I don't think there's much that can be done about that; it's comparable to choosing not to check a certificate revocation list. > The format of this option is insufficiently extensible. Many of the > sixteen code points for available services have already been used and > experiences shows new Kerberos services tend to be deployed over time. > Why would you want to selectively invalidate some but not all tickets? > If this option exists, it seems like providing a mechanism to > completely invalidate the cache should be sufficient. Completely invalidating the cache means starting over with public key ops, and reauthenticating to unaffected services that may be in active use at the time. There may be some benefit to invalidating only certain tickets, in cases like emergency rekeying of a single compromised service. I won't speak to the extensibility issue, not knowing much about the Packet Cable context. > Finally security considerations need to discuss the disadvantages of > storing persistent Kerberos tickets. Other deployments of Kerberos > are moving away from doing this and instead storing tickets in > volatile memory. It would be excellent if the write up of this issue > in the security considerations section gave numbers to justify the > need for persistent tickets, although requiring this would be > excessive. Keeping Kerberos tickets for the long term is probably not a great idea, though since the CCD is presumably storing a public key pair anyways, the usual reasons concerning limited exposure after a compromise of the device don't apply as much. The difficulty of revocation is a more interesting issue. However, since I'd expect the CCD is likely to reconnect and reauthenticate to the system on power-up, avoidance of a huge server load spike after a power outage by retaining tickets for a while would be a good thing, especially with PKINIT. (As would randomized delays, if the retained tickets are found to have already expired at power-up time.) Oh, and an editorial issue: "Persist" is not a transitive verb in any English-language dictionary I've checked; it doesn't take an object. "The CCD persists Kerberos tickets" is just wrong. "Persist" is what the tickets do; it's not done to them. Perhaps "retain" or "store" should be used, maybe specifically mentioning persistent storage? ("Persistent", instead of "persisted", is fine as an adjective.) Ken _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt… Sam Hartman
- [dhcwg] Re: Comments on draft-ietf-dhc-pktc-kerb-… Ken Raeburn
- Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-… Paul Duffy
- Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-… Sam Hartman