[7826] in Kerberos
Re: destruction of Kerberos credentials upon logout
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Aug 21 19:29:33 1996
To: wolfgang@wsrcc.com (Wolfgang Rupprecht)
Cc: kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 21 Aug 1996 19:18:46 -0400
In-Reply-To: wolfgang@wsrcc.com's message of 20 Aug 1996 23:46:26 -0700
>>>>> "Wolfgang" == Wolfgang Rupprecht <wolfgang@wsrcc.com> writes:
Wolfgang> hartmans@MIT.EDU (Sam Hartman) writes:
Wolfgang> I tend to think that its almost always a mistake to
Wolfgang> embedd policy in hardwired code.
I would agree that it is sub-optimal at least. Honestly, I
don't think we have the resources to implement the solution you
propose at the current time. If it were a user-by-user configuration
choice, and if the defaults were reasonably secure, it would be very
useful.
Even then, I think it is reasonable to make it harder to make
policy decisions that tend to lead to insecure situations. For
example, I think I would object to a policy mechanism that allowed
per-tty caches with manual destruction for the reasons I stated in my
message to Ken.
Wolfgang> In the case of credential caches, its a shame that the
Wolfgang> user that creates the credentials doesn't have more
Wolfgang> control of the nameing, merging and destruction
Wolfgang> policies.
Wolfgang> For example, I can see several desirable scenarios:
Wolfgang> Then there is the the orthogonal overwrite/merge choice:
Wolfgang> Each new kinit/login clears the old cache by the
Wolfgang> same name and creates a new cache from scratch.
Wolfgang> Ech new kinit/login merges its credentials with ones
Wolfgang> already there.
I'm not convinced merging credentials actually ends up being
useful. The problem is that the ccache has a default principal which
is used as the client in almost all circumstances. I thought it would
be kind of useful to have tickets for several realms in my ccache at
once, so I hacked a kinit to produce the situation by merging the
caches. It turns out that it really doesn't help, because when I
authenticate to a system not in the Athena realm, it still tries to
authenticate hartmans@ATHENA.MIT.EDU to that realm, even though I had
a TGT for user@remote-realm. Fixing the library to choose principals
based on what tickets in the cache would add significant complexity.
Honestly, I'd rather see libkrb5.a grow smaller not larger, and I
don't see that the benefits in this case justify the costs. If you
have applications that can effectively use merged credentials, submit
a patch to kinit.
Wolfgang> Then there is the destruction issue:
Wolfgang> Destroy all of the cache.
Wolfgang> Destroy only the tickets this kinit/login created
Wolfgang> directly or indirectly.
The ccache API doesn't allow for either tracking who created
what, nor for partial destruction of a ccache. Again, since merged
ccaches aren't that useful, I don't see a strong reason to rewrite the
API in this regard.
Wolfgang> Destroy the cache by reference count. The last guy
Wolfgang> out turns off the lights.
This would be reasonable and probably required if you had a
per-uid ccache.
Wolfgang> It would be good to see an easy way for the user to be
Wolfgang> able to configure these policy issues via a .krbrc file.
Agreed. If you happen to get around to writing this, I would
certainly be interested in your results. (I'm not implying it is
unreasonable to propose ideas if you don't have time to implement
them, simply that I too would like to see an implementation. Also,
you could set options like default forwarding, default encryption,
default renewable lifetime, etc.
Wolfgang> Just trying to thow up some ideas.
Wolfgang> -wolfgang -- Wolfgang Rupprecht <wolfgang@wsrcc.com>
Wolfgang> <http://www.wsrcc.com/> PGP key available via finger,
Wolfgang> keyservers, and WWW
