capaths questions

Jeffrey Hutzelman jhutz at cmu.edu
Mon May 17 15:42:50 EDT 2004



On Monday, May 17, 2004 14:28:13 -0400 Derek Atkins <warlord at mit.edu> wrote:
> 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.

The KDC doesn't get to choose paths; the client does.

If a client in FNAL.GOV knows that FNAL.GOV and ANL.GOV both share keys 
with ATHENA.MIT.EDU, but doesn't know that they share keys with each other, 
then it may construct a path to ANL.GOV through ATHENA.MIT.EDU.

The ATHENA.MIT.EDU KDC is in a position to detect this and prohibit it if 
it wishes (it sees a request from user at FNAL.GOV using a 
krbtgt/ATHENA.MIT.EDU at FNAL.GOV ticket to ask for a 
krbtgt/ANL.GOV at ATHENA.MIT.EDU), but it is unlikely to care.

The KDC in ANL.GOV is also in a position to detect this -- it sees a 
request from user at FNAL.GOV using a krbtgt/ANL.GOV at ATHENA.MIT.EDU ticket to 
ask for some @ANL.GOV service.  It could reject the ticket based on KDC 
policy, or accept it, add ATHENA.MIT.EDU to transited-realms, set 
transited-policy-checked or not as appropriate, and let the service decide.

However, the FNAL.GOV KDC has no opportunity to detect this, or to 
influence the choice once it is made.  Once the client has decided to use 
the via-MIT path, all the FNAL.GOV KDC will see is a request for 
user at FNAL.GOV using a local TGT to request a 
krbtgt/ATHENA.MIT.EDU at FNAL.GOV.  And if it's not going to grant that, then 
the realms may as well not have shared keys to begin with.


Of course, in the reverse case, things work fine.  That is, if there is no 
direct shared key, and the client thinks there is, it can request 
krbtgt/ANL.GOV at FNAL.GOV and the FNAL.GOV KDC can response with a 
krbtgt/ATHENA.MIT.EDU at FNAL.GOV ticket.  This is the routes-are-in-the-KDC's 
model, and it is equivalent to configuring an internet host with only a 
default route instead of explicit routes to every other network on the 
internet.

-- Jeff


More information about the krbdev mailing list