capaths questions
Nicolas Williams
Nicolas.Williams at sun.com
Tue May 18 11:38:06 EDT 2004
On Tue, May 18, 2004 at 10:50:06AM -0400, Jeffrey Altman wrote:
> Here is my take on the situation:
>
> 1. The current requirement that all paths be specified is too
> complicated for the most common cases in which the recursive path
> traversal in the client would be just fine. Therefore, I would
> like to see recursive path traversal be used when an explicit path
> is not specified.
Path validation needs a better language that does not require full path
specification.
I imagine, for example, a language where one can say "not through COM
from *.FOOBAR.COM," "two-hops max from *.FOO.COM," "hierarchical
transits, but not through TLR (top-level realm), shortcuts in hierarchy
traversal allowed from FOO.COM," etc...
Rules would have two parts: one matching client principal realm names
(using some sort of expression, globs, regexes or just the simple
domain_realm '.' matching) the other one listing restrictions.
These rules should be applicable per-realm, per-principal and/or per-
application profile.
The client also need not have a complete database of x-realm paths; a
list of shortcuts should suffice (i.e., always do hierarchical x-realm
transitting modulo shortcut availability).
> 2. KDC checking of the transitive path should be optional. I like
> Doug's suggestion of the NO_KDC_CHECK and KDC_CHECK_ALL bits. In
> general I believe that the final determination of whether a path
> should be accepted or not is the responsibility of the application
> service. Of course, if there are certain paths that a realm
> administrator does not want to trust it should be able to prevent
> the KDC from issuing service tickets. But it should be an option
> and not a requirement.
Yes, I too like Doug's proposal, though I might name the bits
differently:
- TRANSIT_CHECK_REJECTIONS (reject unacceptable paths, but don't set
transited policy checked bit on issued tickets)
- TRANSIT_CHECK_ALL (reject unacceptable paths, set transited policy
checked bit on issued tickets)
Cheers,
Nico
--
More information about the krbdev
mailing list