Split IAKERB for local KDCs cross-realm setup?

[Alexander Bokovoy]

Hi,

now that we've got IAKERB protocol remote realm discovery implemented[1]
and fixed[2] shortcuts where IAKERB exchanges skip AS-REQ, going to TGS-REQ
or even directly to AP-REQ, one remaining bit of our local KDC work is
to be able to establish cross-realm relationship between two local KDCs
and allow users to obtain their initial TGT locally while requesting the
service ticket over the cross-realm.

Right now this does not work because IAKERB mechanism implementation is
a true proxy: whatever Kerberos payload is produced by the IAKERB client
side mech, gets transported over the application protocol to the server
side and there IAKERB server side mech will process it. As a result,
IAKERB server side mech would handle a TGS-REQ where an initial ticket
presented by the client is the one issued by the KDC on the client side.
Obviously, server side IAKERB implementation has no access to that KDC.

 From my comment in the PR#1415:
-----------------------------------------------------------------------
In the network trace below .221.2 is the client, .221.3 is the server.
The server attempts to lookup client's realm through a locator plugin
over DNS, fails and sends a failure:

$ tshark -r ~/Downloads/iakerb-two-realms.tcp 
     1   0.000000 192.168.221.2 → 192.168.221.3 TCP 74 51336 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=3001061984 TSecr=0 WS=128
     2   0.000018 192.168.221.3 → 192.168.221.2 TCP 74 445 → 51336 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=3521582579 TSecr=3001061984 WS=128
     3   0.000026 192.168.221.2 → 192.168.221.3 TCP 66 51336 → 445 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3001061984 TSecr=3521582579
     4   0.000144 192.168.221.2 → 192.168.221.3 SMB2 342 Negotiate Protocol Request
     5   0.000150 192.168.221.3 → 192.168.221.2 TCP 66 445 → 51336 [ACK] Seq=1 Ack=277 Win=64896 Len=0 TSval=3521582579 TSecr=3001061984
     6   0.004212 192.168.221.3 → 192.168.221.2 SMB2 378 Negotiate Protocol Response
     7   0.004233 192.168.221.2 → 192.168.221.3 TCP 66 51336 → 445 [ACK] Seq=277 Ack=313 Win=64128 Len=0 TSval=3001061988 TSecr=3521582583
     8   0.010218 192.168.221.2 → 192.168.221.3 SMB2 1423 Session Setup Request
     9   0.012756 192.168.221.3 → 192.168.221.1 DNS 86 Standard query 0x2068 URI _kerberos.AB.LOCALKDC.SITE
    10   0.014026 192.168.221.1 → 192.168.221.3 DNS 151 Standard query response 0x2068 No such name URI _kerberos.AB.LOCALKDC.SITE SOA ns0.centralnic.net
    11   0.014163 192.168.221.3 → 192.168.221.1 DNS 91 Standard query 0xa805 SRV _kerberos._udp.AB.LOCALKDC.SITE
    12   0.014548 192.168.221.1 → 192.168.221.3 DNS 156 Standard query response 0xa805 No such name SRV _kerberos._udp.AB.LOCALKDC.SITE SOA ns0.centralnic.net
    13   0.014599 192.168.221.3 → 192.168.221.1 DNS 91 Standard query 0x3f7a SRV _kerberos._tcp.AB.LOCALKDC.SITE
    14   0.014883 192.168.221.1 → 192.168.221.3 DNS 156 Standard query response 0x3f7a No such name SRV _kerberos._tcp.AB.LOCALKDC.SITE SOA ns0.centralnic.net
    15   0.015138 192.168.221.3 → 192.168.221.2 SMB2 143 Session Setup Response, Error: STATUS_LOGON_FAILURE
-----------------------------------------------------------------------

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.

Another possible way to solve this is to recognize that the we have a
local client's realm creds already and no notion about the server realm
yet.  Perform a remote realm discovery and then, if the local and the
remote realms are different, attempt a local TGS-REQ to see if a
cross-realm referral could be obtained. If that's possible, continue
with this referral to the server side IAKERB.

[1] https://github.com/krb5/krb5/pull/1415
[2] https://github.com/krb5/krb5/pull/1416

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