Ticket History #8579: duplicate caching of some cross-realm TGTs

Okay, I see the problem. In the traditional model of credential
caching, the upper layer checks the cache for a credential, doesn't
find it, goes out and gets it, and puts it in the cache. In a
concurrent scenario a few processes might write duplicate entries to
the cache, but that's (hopefully) rare and pretty harmless, so under
this model we don't need the ccache layer to do any duplicate
suppression.

During a TGS request the KDC might hand us a credential we didn't ask
for, such as a referral or an alternate TGS cred. Caching these
credentials breaks the model--since we never wanted these credentials
at the upper layer, the upper layer never checks for them. That also
calls into question the value of caching those unsolicited responses--
they won't be useful if the same higher-level operation is repeated
(or even a similar one, such as a request resulting in a refferal to
the same realm). They would only save a TGS request if an unrelated
operation happens to ask for that cross-realm TGT principal.

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
unfortunately isn't quite as simple as removing code due to the
current design of step_get_tgt(), but it shouldn't be too hard.)
Handling duplicates inside the ccache layer has a few problems:

* FILE ccaches are essentially append-only, so suppressing duplicates
by removing the old entry can't be implemented efficiently in the most
common ccache type. (Heimdal implements removal by overwriting
selected parts of the cred entry so that it becomes invisible to
traversal, but that doesn't prevent the ccache from growing
unacceptably large.)

* Suppressing duplicates by ignoring the new credential isn't the
behavior we want for ccache config entries. We would ideally like to
be able to change the value of config entries that already exist by
writing a new credential entry, although that doesn't currently work
(krb5_cc_get_config() stops when it sees the old entry).

* Copying a moderately-sized ccache would become O(n^2) as we do a
full read of the ccache for each entry.

In your patch, you noted a krb5_cc_remove_cred() call inside
krb5_cc_store_cred(). That is an accidental leftover; see
http://krbdev.mit.edu/rt/Ticket/Display.html?id=7906

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.

Agreed.

Remove stray exit in t_referral.py

Commit 1dc619624421002b1e64d3b8c7e270508381b3e6 included a stray
"exit(0)" for debugging. Remove it.

https://github.com/krb5/krb5/commit/73e40a81df07d035d1a86b871012d022d38fb9e3
Author: Greg Hudson <ghudson@mit.edu>
Commit: 73e40a81df07d035d1a86b871012d022d38fb9e3
Branch: master
src/tests/t_referral.py | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)