Split IAKERB for local KDCs cross-realm setup?

[Nico Williams]

On Fri, Mar 28, 2025 at 11:49:09AM -0400, Greg Hudson wrote:
> Do we expect a local operation to succeed in this use case?  That is,
> [...]

Possibly.  The initiator might only have x-realm TGTs for allowed
destinations.  The initiator might have a TGT for some realm whose KDCs
it can reach, but can't reach the destination's while the destination
can't reach the initiator's TGT's realm's KDCs.

Consider a case of traversing from "inside" to "the DMZ" or similar
where you have a separate realm for that destination.  You might have
access to the "inside realm's KDCs" and not "the DMZ realm's KDCs".

Or consider a mobile device that can be "inside" via VPN or "outside"
when the VPN is down, and when "outside" it can only reach some realms'
KDCs via IAKERB and when "inside" it can't reach a different set of
realms' KDCs.  The mobile device case is not too outlandish.

> One concern is that IAKERB was originally designed for initiators with very
> limited connectivity.  Attempting direct KDC requests in such an environment
> could lead to a timeout.  Having a cached TGT for a realm isn't strong
> evidence that the initiator can contact that realm, as the credentials may
> have been obtained using a previous invocation of IAKERB.

Options:

1) Local configuration.  The initiator knows which realms have
   initiator-reachable KDCs.

   Ugh.  More local configuration.

2) The initiator tries local first at the cost of timeouts.

   Ugh.

   Well, maybe this is not so bad: KDC discovery shouldn't timeout, and
   if sites use split-horizon DNS then it's not so bad because the DNS
   can be configured so the initiator will discover zero KDCs for realms
   with unreachable KDCs.  But demanding split-horizon DNS is not
   reasonable.

3) The initiator does IAKERB all the way, but if it gets a KRB-ERROR
   saying some realm's KDCs were unreachable then it tries locally and
   if it succeeds it continues[*] with IAKERB.  

   [*] Currently any KRB-ERROR causes context establishment failure, so
       (3) cannot work unless an option is added to the IAKERB-HEADER to
       change this to give the initiator a chance to try locally.

       Negotiating this might be too difficult or impossible.  The
       initiator would say this is what they want.  The mechanism on the
       initiator side might never know if the acceptor supported this.
       The application would know and delete the context, if the
       application has a way to indicate context establishment failure
       beyond conveyance of error tokens.

4) Like (3) but if the mechanism is not extended or if the acceptor does
   not support the extension (and so bails at the first KRB-ERROR) then
   cache realm unreachable errors and next time do (2) for those realms.

   Ugh.  Horrible.

5) Implement some way to discover KDC reachability without timeouts and
   without split-horizon DNS.  A new RR type might help, hopefully with
   DNSSEC not being absolutely required.  Perhaps the RR type's RDATA
   would just be a realm name, and the RRSet would indicate all the
   realms from which the target is known reachable (or the inverse).

   This wouldn't work when some initiators from realm A can reach B's
   KDCs but not other initiators from realm A because what might matter
   is the initiator's network location rather than their realm.

(2) and (4) are unreasonable.  (3) and (5) are not great: they will
require spec work, but (5) should require the least amount of work
though it also wouldn't be a complete solution.

(1) is probably the only reasonable option.  Probably with either a list
of known-reachable realms or a list of known-unreachable realms.

> That said, I don't have any evidence that IAKERB is being used in the
> environment it was designed for.

Eh, IAKERB was designed eons ago.  The environment that users need it
for today and the environment it was designed for need not be the same.

Nico
--