Return-Path: Received: from uriel.oankali.net (uriel.oankali.net [208.111.40.94]) by krbdev.mit.edu (Postfix) with ESMTPS id 5760D3EF33 for ; Mon, 24 Apr 2017 14:56:10 -0400 (EDT) Received: from [192.168.1.9] (pool-100-2-16-35.nycmny.fios.verizon.net [100.2.16.35]) (authenticated bits=0) by uriel.oankali.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v3OIu7Te017574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Apr 2017 14:56:09 -0400 Date: Mon, 24 Apr 2017 14:56:06 -0400 (EDT) From: Richard Silverman To: Greg Hudson via RT Subject: Re: [krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 RT-Send-Cc: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-Length: 617 > So I think my preferred solution for this scenario is to change > get_cred.c not to cache answers it didn't ask for. This makes sense to me, and it also (I think) solves another problem I’ve run into that I’ve dubbed “ccache poisoining.” If a client receives an inaccurate referral and caches it, the cached referral can prevent the client from following an available successful path for a different service ticket later on. Of course, the incorrect referral is the root problem, but these things happen in complex multi-platform/realm arrangements, so it’s nice to contain the breakage. -- Richard