-allow_tix and renewable tickets

[Greg Hudson]

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.