-allow_tix and renewable tickets
checker at d6.com
Wed Nov 28 14:02:16 EST 2012
> Since the last time we talked about this, I realized that as of MIT
> krb5 1.7, we *have* been looking up the client DB entry for most TGS
Cool, that makes it easier! I will hopefully roll up all my
"effectively ban users" patches soon and send them on, I need to port
them up to the head at some point, I'm languishing back in 1.9 land still.
Not sure I understand the S4U aspect, but I haven't looked at it in a
while, so maybe I forgot whether I made that change too.
On 2012/11/28 08:16, Greg Hudson wrote:
> On 11/27/2012 03:17 PM, Chris Hecker wrote:
>> I've been thinking about renewable tickets recently, and I haven't had a
>> chance to test this yet, but does a renew operation check allow_tix or
> I believe it does not, because renewal happens via a TGS request, and in
> the original architecture, TGS requests do not look up the client DB entry.
>> I assume it "should"
>> check the client's not locked out before allowing a renew, right, since
>> the whole point of renewable tickets is to increase convenience without
>> giving up on much security, so you want a long renew lifetime but be
>> able to revoke priviledges in the middle of it?
> That reasoning seems valid.
> Since the last time we talked about this, I realized that as of MIT krb5
> 1.7, we *have* been looking up the client DB entry for most TGS requests
> (unless the request is an S4U2Self or S4U2Proxy request, or the server
> principal DB entry has the KRB5_KDB_NO_AUTH_DATA_REQUIRED bit set). We
> just aren't doing anything with it (yet) besides authorization data
> So it would probably be reasonable to look up the client DB entry in all
> cases (though for S4U requests, we'd need to look up the subject DB
> entry instead) and make that available to validate_tgs_request(), which
> could check the client allow_tix flag.
More information about the krbdev