>>>>> "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.