[krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs

Greg Hudson via RT
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
_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs

Greg Hudson via RT
> 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

_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [krbdev.mit.edu #8579] duplicate caching of some cross-realm TGTs

Greg Hudson via RT
In reply to this post by Greg Hudson via RT
>>>>> "Greg" == Greg Hudson via RT <[hidden email]> 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.


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Loading...