how to "ban" clients?

[Chris Hecker]

Obviously any real refactor of kdc code is something way out of 
scope/expertise for me to do (I only changed the silly 
pass-giant-struct-by-value thing and fixed the dupe struct), but I did 
docs for the new profile vars and whatnot.  The change is pretty trivial 
in terms of lines of code, it's 95% profile reading.

What I'll do is put up a page with the various patches I've made to the 
KDC, and send out a link, and you guys can take a look.  I think there 
are 5 in total (pass-by-value fix, u2u allow_svr fix, this 
check-allow_tix-on tgs_req fix/feature, make vague_errors a profile bool 
instead of compile time const (which turned out to be pretty useless for 
various reasons I'll write up on the page), and fix the dupe 
krb5_realm_params issue).

I'm not sure of the best way to write an automated test for this.  Is 
there an example of a complex test like this in the source tree?  You'd 
have to simultaneously be talking to the kadm5 interface to change the 
flags and be talking to the kdc.  I could do it in perl with my patched 
Authen::Krb5(::Admin) modules, but it'd be a fairly big test in C.

Chris




On 2011/08/07 22:51, Greg Hudson wrote:
> On Wed, 2011-07-27 at 06:35 -0400, Chris Hecker wrote:
>> Okay, I implemented this today.
>
> We may add a feature like this at some point, in order to provide fast
> revocation for high-value services.  In order to get any solid security
> guarantees, the service would need to set a short maximum lifetime, and
> would need to force reauthentications upon ticket expiration.
>
> I can't provide any timeline, though.  Relative to your patch, we would
> likely need to address:
>
> * Precisely how the client lookup should be done (what flags,
> basically).  Canonicalization of the client principal should not
> generally be needed since it will have been done during the AS request.
>
> * Consideration of edge cases, such as when the client principal entry
> has been deleted or renamed or deleted and recreated since the AS
> request.
>
> * Consideration of whether to extend the DAL interface's TGS
> verification function to take the client DB entry as input when
> available.
>
> * A long-overdue refactoring of the TGS code path before additional
> complexity is added to it.
>
> * Documentation.
>
> * Automated test cases.
>
>