capaths questions

[Nicolas Williams]

On Tue, May 18, 2004 at 11:06:49AM -0500, Douglas E. Engert wrote:
> 
> 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! 

It's actually quite simple since most folk will get by with a default
rule allowing for any transited path and those who don't will generally
have a few such rules.

> 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. 

Specifying exceptions is simpler than specifying all valid paths!

> 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. 

But the KDC still needs a policy.

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

I think they do.

> > 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.

Yes.  My point stands.

Nico
--