Return-Path: <res@qoxp.net>
Received: from uriel.oankali.net (uriel.oankali.net [208.111.40.94]) by krbdev.mit.edu (Postfix) with ESMTPS id 5760D3EF33 for <rt-comment@krbdev.mit.edu>; 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 <rt-comment@krbdev.mit.edu>; Mon, 24 Apr 2017 14:56:09 -0400
Date: Mon, 24 Apr 2017 14:56:06 -0400 (EDT)
From: Richard Silverman <res@qoxp.net>
To: Greg Hudson via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs 
In-Reply-To: <rt-8579-47367.1.69724808175815@krbdev.mit.edu>
Message-ID: <alpine.OSX.2.20.1704241456030.34905@darwin.oankali.net>
References: <rt-8579-47367.1.69724808175815@krbdev.mit.edu>
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