Split IAKERB for local KDCs cross-realm setup?

[Alexander Bokovoy]

On Пят, 28 сак 2025, Greg Hudson wrote:
>On 3/27/25 04:52, Alexander Bokovoy via krbdev wrote:
>>IAKERB already allows for the acceptor to respond with
>>KRB_AP_ERR_IAKERB_KDC_NOT_FOUND in case the KDC was not found, so may be
>>what we miss is a check in the IAKERB initiator code to see if that KDC
>>is actually our own. Then we can perform local operation in the hope to
>>obtain a cross-realm referral.
>
>Do we expect a local operation to succeed in this use case?  That is, 
>will the initiator's libkrb5 have the configuration needed to contact 
>the local KDC once it knows the realm name, without the IAKERB proxy 
>through smbserver?  (As a corollary, in the local-realm case are we 
>only using IAKERB for realm discovery, with the subsequent proxying of 
>AS-REQs and TGS-REQs happening as a side effect?)

At least for the UNIX domain socket-based KDC yes, we have strong
indication the initiator has enough information to contact the KDC.
This information must be part of the configuration already because UNIX
domain socket-based KDC transport has no discovery means.

>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.
>
>That said, I don't have any evidence that IAKERB is being used in the 
>environment it was designed for.

My understanding is that at least Microsoft is not planning to apply any
additional logic to limit/handle local KDC knowledge beyond the basic
realm discovery. This comes from my discussion with Steve Syfuhs.
However, this also means that as long as the initiator logic we discuss
in this thread is based on the already existing
KRB_AP_ERR_IAKERB_KDC_{NO_RESPONSE,NOT_FOUND} messages, it would be
compatible, at least at the cost of possible KDC locator timeouts.


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