Return-Path: Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) by krbdev.mit.edu (Postfix) with ESMTPS id E05713EF33 for ; Mon, 24 Apr 2017 16:13:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id B86DB21768 for ; Mon, 24 Apr 2017 16:13:54 -0400 (EDT) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsU1P5lQZe43 for ; Mon, 24 Apr 2017 16:13:54 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-174-63-87-87.hsd1.ma.comcast.net [174.63.87.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA for ; Mon, 24 Apr 2017 16:13:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A9C2580F9B; Mon, 24 Apr 2017 16:13:52 -0400 (EDT) From: Sam Hartman To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs References: Date: Mon, 24 Apr 2017 16:13:52 -0400 In-Reply-To: (Greg Hudson via's message of "Mon, 24 Apr 2017 14:27:33 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain RT-Send-Cc: X-RT-Original-Encoding: iso-8859-1 Content-Length: 1865 >>>>> "Greg" == Greg Hudson via RT writes: Greg> During a TGS request the KDC might hand us a credential we Greg> didn't ask for, such as a referral or an alternate TGS cred. Greg> Caching these credentials breaks the model--since we never Greg> wanted these credentials at the upper layer, the upper layer Greg> never checks for them. That also calls into question the Greg> value of caching those unsolicited responses-- they won't be Greg> useful if the same higher-level operation is repeated (or even Greg> a similar one, such as a request resulting in a refferal to Greg> the same realm). They would only save a TGS request if an Greg> unrelated operation happens to ask for that cross-realm TGT Greg> principal. There's one thing I'd recommend thinking about at least. What happens in a client-driven cross-realm situation. That is, what happens if the client has a well-populated domain_realms section in its config file. Will you change what tickets are retained? If so, do we care? That's the only case where I believe cross-realm tickets are particularly likely to be used. I like the security properties of your solution better than the current behavior though. Currently, we interpret a TGS referral from a KDC as meaning two things: 1) Use the referred realm along the path to the requested principal. 2) This ticket is a valid TGT for any contact to the referred realm. We may not use that ticket generally, but if we cache it, an attacker might be able to convince us to do so. However, if we don't cache the intermediate ticket, we're very close to revising the second assertion from the KDC to "use this TGT for this one operation." That's more conservative in a way that I like. I admit that with the KDCs I'm aware of, it doesn't buy you anything in practice.