-allow_tix and renewable tickets

[Chris Hecker]

> 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

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.

Thanks,
Chris


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
>> not?
> 
> 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
> processing.
> 
> 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.
> 
>