capaths questions

[Derek Atkins]

"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.  :)

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