Content-Type: text/plain; format=flowed; charset=US-ASCII
X-RT-Original-Encoding: us-ascii
Content-Length: 1469

Hello,

Under certain circumstances, we're seeing duplicate caching of some
cross-realm tickets. Specifically:

1 Kerberos principal user@A tries to establish a GSSAPI security context
   with GSS hostbased-service name host@foo.

2 The client tries its own realm first for "host/foo@A"; the service
   principal should be there, but it's missing.

3 The A KDC refers the client to realm B.

4 The B KDC refers the client back to realm A, and the attempt ends in a
   KDC policy error from A due to the lineage check.

In this case for us (MIT Kerberos 1.15.1), another copy of the krbtgt/B@A
referral TGT from step 3 is added to the ccache every time. With a process
that, say, ssh'es to thousands of hosts periodically, the ccache grows to
an impractical size.

Note that the second referral TGT from step 4 is not cached at all, let
alone repeatedly -- which also seems odd but is not an immediate problem.

One might wonder whether the looping referrals are themselves a
mistake. Actually these optimistic referrals are intentional, addressing
certain aspects of our infrastructure; the missing host principal is the
real breakage here. But it's really not relevant; the duplicate caching is
a problem on its own.

I'm attaching a patch that fixes the issue. Do note the accompanying
commit message, as it has some more comments. As it indicates, I'm not
sure this is the right fix -- so please consider it a first stab at a
solution.

Thanks,

Richard E. Silverman