Split IAKERB for local KDCs cross-realm setup?

[Greg Hudson]

On 3/28/25 14:55, Alexander Bokovoy wrote:
>>   [*] 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.

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

   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.

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.