Split IAKERB for local KDCs cross-realm setup?

[Nico Williams]

On Fri, Mar 28, 2025 at 05:07:27PM -0400, Greg Hudson wrote:
> > 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.
> 
> This would be a divergence from the spec.  This isn't necessarily
> showstopper, especially as the spec is still a draft, but I wanted to make
> note of it.  Section 3 says:

You're right, it's not a showstopper.  IAKERB is not an RFC yet and now
is the time to make changes like this one.

>   When the GSS-API acceptor is unable to obtain an IP address for a KDC
>   in the client's realm, it sends a KRB_ERROR message with the code
>   KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client in place of an actual
>   reply from the KDC, and the context fails to establish.
> 
> and there is similar text for KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE.  This
> restriction seems unnecessary; I don't see any mechanical reason why it
> wouldn't work for the initiator to continue the exchange after locally
> handling the requests for the current realm.

Right.  Either have it so the context establishment does not fail yet,
or have it so the initiator can request that context establishment does
not fail yet.

Since the initiator could always use KRB-ERRORs to guide its behavior...
I think it's best to say that the only KRB-ERRORs that should cause
context establishment to fail are ones in response to AP-REQs [0].

For example, imagine an initiator that uses a "DNS resolver search list"
to canonicalize service principal names w/ short hostnames w/o DNS
lookups, just by asking for a service ticket for each FQDN constructed
with the search list, one by one, until one works or all fail.  Such an
initiator might elicit numerous KRB-ERRORs.

[0] We've wanted an RFC4121 extension to make some AP-REQ errors
    retriable within the same context establishment, such as the Ticket
    being encrypted in an older service key, which happens in some
    environments when rotating service keys or bringing new members into
    a cluster, etc.

> Any update to the draft should be handled through the kitten WG, but I also
> want to note that if the draft is updated, the new text should make it clear
> that the GSS tokens containing the couldn't-be-proxied request and error
> response must appear in the KRB-FINISHED transcript, like any other
> pre-AP-REQ tokens in the exchange.

Yes.

Nico
--