Split IAKERB for local KDCs cross-realm setup?

[Alexander Bokovoy]

On Пят, 28 сак 2025, Nico Williams wrote:
>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.

Yes, these all sound like reasonable scenarios. Some of that information
may be discovered implicitly (based on a pre-configured transport like UNIX
domain socket), and some of it might be explicitly configured by
external software. For example, both Samba and SSSD do pin KDCs to the
ones currently chosen by winbindd and SSSD for communication, to
preserve site-aware communication, by creating cache files picked up by
the corresponding locator plugins. So it is already in place, at a
higher (application) level.

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

For the specific case of local KDCs we would have a strong indication
that the local KDC is reachable if it is accessible over UNIX domain
socket. That's something an initiator might know in advance because it
is already is in the 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.

local (UNIX domain socket-based) KDC has no additional discovery
mechanism right now other than the explicit local configuration. So this
might work already. Perhaps we can have a flag that asks for immediate
configured KDCs rather than a full discovery? This would make (1) and
(2) blended, effectively.

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

My initial idea was to intercept one of those two KRB-ERROR responses we
get back from the acceptor for not being able to identify a KDC or reach
it and don't return to the application yet. Instead, perform similar
operation locally. Initiator currently does not react on
KRB_AP_ERR_IAKERB_KDC_{NO_RESPONSE,NOT_FOUND}, but it could implement
the logic for (1) instead.

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

Say, k5_locate_kdc()/k5_locate_server() API could be extended to
indicate only immediate reachable (local) KDCs (UNIX domain socket or
over localhost), then we would have the list implicitly.

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

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland