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