capaths questions

[Derek Atkins]

"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?

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

> 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