capaths questions

[Douglas E. Engert]

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?


Because that is the way it was written. Any mod more complicated then this
would not have been accepted into the source code at that time. This was a 
big improvment over the need to walk the realm tree and require 
realms like ORG to share keys with a EDU realm. We got the MIT people to
accept this, but never got the DCE people to accept it. (Let alone Microsoft
that did not use Kerberos then.)

I think I can also come up with examples, where depending on the user vs 
service realms there may be different acceptable paths between intermediate
nodes. 

The set of realms sharing keys could be a mesh, with many possible paths.
Based on policy, some realms may not be accetable in some cases. 

Its really the same as a network routing problem, but the end node will
double check the route was as expected!  
  

I have to run, and have not looked at this much in 9 years. Will have to read
up on this over the weekend.



> 
> > ./t_walk_rtree RAEBURN.ORG SECURE-ENDPOINTS.COM
> >
> > krbtgt/RAEBURN.ORG at RAEBURN.ORG
> > krbtgt/DEMENTIA.ORG at RAEBURN.ORG
> > krbtgt/SECURE-ENDPOINTS.COM at DEMENTIA.ORG
> >
> >>
> >> it seems that the code could infer that line from the previous
> >> DEMENTIA.ORG line.
> >
> > It does not work that way today.
> 
> That wasn't the question -- it's obvious it doesn't work that way
> today, but _why_ doesn't it work that way?
> 
> >>
> >> I understand that having each path explicitly specified does provide
> >> more flexibility.  But is this flexibility actually desirable?
> >
> > I think the flexability is desirable. There are situations where two realms
> > share keys, and would not expect any other realms in a transited path. Yet
> > a client could get a TGT that would be on the default path.
> 
> I think if you assume "shortest path" you still get what you want.
> 
> > Assume realms A, B ,C, D  where A, B, and C all share keys,
> > and B and D share keys. So the expected path between A and C is direct.
> > But A to D would have B in the transited path.
> 
> Ok, so clearly the only capath list you need is:
> 
>     D = B
> 
> Everything else is directly connected. 

I think so, as the client will ask a KDC to give it a ticket to the 
next realm closest to the final realm.  
  
> 
> > User could get TGT for B at A, by going to D. The user could use the
> > B at A to get a C at B to get service ticket on C. This would then have B in the
> > transited field. But since A and C share keys, should this be considered an
> > attack? Maybe. A and C may only be sharing keys with B so they can get to D.
> > The end server has no way to know that A and C should never have B in the
> > transited field other the the capath code.
> 
> This is a different case here than Sam's question.
> 
> > In your case I think it is needed, as the the code will fall back to using
> > the DNS based path code, and assume the path  DEMENTIA.ORG  to RAEBURN.ORG
> > exists.
> 
> But why is it assuming this when it's quite clear from the
> configuration that DEMENTIA requires going through ATHENA?
> If the algorithm were changed to do the following:
> 
> For each REALM I want to access (starting from the destination
> and working back towards me:
> 
> 0) using the "current" last-hop
> 1) if there is a local key for the last-hop, stop.  I have a full path.
> 2) if there is an entry in the capath list, I need to transit via
>    that realm.  Push the current last-hop into the transit list and
>    make the new entry the new last-hop.  Then go to 0.
> 3) if there is not a local key, then use other methods (DNS?) to try
>    to find a transited path.
> 
> The key here is the recursion at #2 where it looks BACK into the
> capath configuration for each transited path.  I think this still
> gives us some flexibility, but admittedly not as much as we had
> before.
> 
> The key is that if you have to hop from A->B->C->D, clearly you also
> would need to hop from A->B->C, so why should you need to specify
> this?  If you had an A->C shortcut, why wouldn't you use it when
> contacting C directly in addition to when you want to transit through
> C to D?

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