capaths questions

[Douglas E. Engert]

OK, here is another contrived example similiar to Ken's,
but with a few extra realms.

Cross realm keys (- or |) are shared by these realms:

  A - B
  |   |
  C - D - E
      |   |
      F - G - H
          | 
          I  


Say C, F and I are all student run, where as A, B, D, E, G, H are official,
with B and E for official biz only. So user in A wants to get to server H, 
he takes offical path A, B, D, E, G, H

If user in A is going to I, he takes student path: A, C, D, F, G, I

How would you handle this with recursive capaths? 
  
(When the DCE people where looking at this problem, they talked in terms 
of going up the realm tree then across then down, if that helps at all 
in how to handle the problem.) 


Derek Atkins wrote:
> 
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
> > Sounds like Ken came up with an example on Friday.
> >
> > But here is another more real world example.
> >
> > FORD.COM and GM.COM have cross realm with AUTOMAN.ORG, so the engineres
> > in ENG.FORD.COM and ENG.GM.COM can comunicate.
> >
> > The accountants in ACCT.FORD.COM have cross realm with ACCT.GM.COM
> > setup via the FORD.COM and GM.COM but use the cross realm using the
> > ACCCOUNTS.COM realm.
> >
> > The engineres don't care if ACCOUNTS.COM is used, but the
> > accountants don't trust AUTOMAN.ORG
> 
> Ok, I can see where you might have multiple paths and want to specify
> the path based on the actual end domains.  But there are always other
> alternatives.
> 
> For example, why don't ACCT.FORD.COM and ACCT.GM.COM just share keys
> with ACCOUNTS.COM directly themselves?  Then they can just bypass the
> FORD/GM top-levels because they clearly don't trust them anyways.  :)

Maybe, but maybe company policy says the top level realm 
does all cross realm outside the organization.

> 
> > Another more realistic example would be Two sites do cross realm
> > say ANL.GOV and FNAL.GOV They both also have students/reasearchers
> >>From say MIT.EDU, so setup cross realm, but never want to see
> > MIT.EDU in a path between the ANL.GOV or FNAL.GOV
> 
> This is irrelevant.  The KDC should _ALWAYS_ choose a direct path in
> lieu of a hop.  If FNAL and ANL directly share a key you should NEVER
> (and I mean 100% never) see an intermediary.  I can envision NO
> policies where you should ever want an intermediary when you have a
> direct link.
> 
> Still, I think the point remains that the client should still recurse
> in the capaths config file,

It comes down to can someome come up with an example where recursive 
lookup does not work.   

> even if you _allow_ a full-path
> specification.  I shouldn't HAVE to specify each path completely,
> although I have been sold on the fact that you should be ALLOWED to do
> so.
> 
> -derek
> 
> > Sam Hartman wrote:
> >>
> >> >>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:
> >>
> >>     Douglas> Derek Atkins wrote:
> >>     >>  "Douglas E. Engert" <deengert at anl.gov> writes:
> >>     >>
> >>     >> > setenv KRB5_CONFIG /tmp/dee.capath.conf > ./t_walk_rtree
> >>     >> RAEBURN.ORG SECURE-ENDPOINTS.COM
> >>     >> >
> >>     >> > krbtgt/RAEBURN.ORG at RAEBURN.ORG >
> >>     >> krbtgt/ATHENA.MIT.EDU at RAEBURN.ORG >
> >>     >> krbtgt/DEMENTIA.ORG at ATHENA.MIT.EDU >
> >>     >> krbtgt/SECURE-ENDPOINTS.COM at DEMENTIA.ORG
> >>     >> >
> >>     >> > Without the SECURE-ENDPOINTS.COM = ATHENA.MIT.EDU line > it
> >>     >> assumes that RAEBURN.ORG shares keys with DEMENTIA.ORG
> >>     >>
> >>     >> I guess Sam's question (or at least MY quesiton) is: WHY does
> >>     >> it make this assumption?  It's clear from the configuration
> >>     >> that I need to go through ATHENA to get to DEMENTIA.  So why
> >>     >> doesn't the capath code recurse through the configuration for
> >>     >> every step in the path?
> >>
> >>     Douglas> Because that is the way it was written. Any mod more
> >>     Douglas> complicated then this would not have been accepted into
> >>     Douglas> the source code at that time. This was a big improvment
> >>     Douglas> over the need to walk the realm tree and require realms
> >>     Douglas> like ORG to share keys with a EDU realm. We got the MIT
> >>     Douglas> people to accept this, but never got the DCE people to
> >>     Douglas> accept it. (Let alone Microsoft that did not use Kerberos
> >>     Douglas> then.)
> >>
> >> OK.  Well we're thinking of changing things not require the duplicate
> >> line.  I.E. you would only need one LHS for any given realm.  We can
> >> do so in a backward compatible manner.
> >
> > Sounds good to me.
> >
> >>
> >>     Douglas> I think I can also come up with examples, where depending
> >>     Douglas> on the user vs service realms there may be different
> >>     Douglas> acceptable paths between intermediate nodes.
> >>
> >> Can you come up with examples where the current code gives you
> >> flexibility that the new code does not and where this flexibility is
> >> needed?
> >
> > --
> >
> >  Douglas E. Engert  <DEEngert at anl.gov>
> >  Argonne National Laboratory
> >  9700 South Cass Avenue
> >  Argonne, Illinois  60439
> >  (630) 252-5444
> >
> >
> 
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available

-- 

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