capaths questions

[Douglas E. Engert]

Nicolas Williams wrote:
> 
> 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...
> 

This is boggling to the mind! 

I would expect one goal it to keep it simple, so the client and server 
can each derive the same path, so as to check the transited field. 

Referrals and the server's setting of the TRANSITED-POLICY-CHECKED
are designed to make life simpler for the clients and servers, and
let their KDCs do some of the work, yet let the client or service do 
all the work if they want. 

I am not sure if these rules make things any simpler to understand and
implement correctly. 

> 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)
>
 
This is not protocol, but database administration, much like the
OK-TO-DELAGATE that some systems support.

> Cheers,
> 
> Nico
> --
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444