>>>>> "Greg" == Greg Hudson via RT <rt-comment@krbdev.mit.edu> 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.