capaths questions

Douglas E. Engert deengert at
Mon May 17 14:08:19 EDT 2004

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 

The engineres don't care if ACCOUNTS.COM is used, but the 
accountants don't trust AUTOMAN.ORG

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

Sam Hartman wrote:
> >>>>> "Douglas" == Douglas E Engert <deengert at> writes:
>     Douglas> Derek Atkins wrote:
>     >>  "Douglas E. Engert" <deengert at> writes:
>     >>
>     >> > setenv KRB5_CONFIG /tmp/dee.capath.conf > ./t_walk_rtree
>     >> >
>     >> > krbtgt/RAEBURN.ORG at RAEBURN.ORG >
>     >> krbtgt/ATHENA.MIT.EDU at RAEBURN.ORG >
>     >> krbtgt/DEMENTIA.ORG at ATHENA.MIT.EDU >
>     >> >
>     >> > 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>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

More information about the krbdev mailing list