how to "ban" clients?
Chris Hecker
checker at d6.com
Mon Aug 8 04:09:10 EDT 2011
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.
>
>
More information about the Kerberos
mailing list