referrals interop

[Andy Polyakov <appro@fy.chalmers.se>]

First of all I want to point out that this is not a problem report, but 
merely an attempt to make subscribers aware of pitfalls in referrals 
handling.

Most Windows users/administrators surely appreciate (well, maybe 
unconsciously:-) how Windows handle referrals to another realm/ad. It's 
so appreciated that one might fall into belief that other clients should 
act in same manner. At least I did:-) Anyway, it should be noted though 
that it apparently does not comply with official Kerberos specification. 
Indeed, quoting RFC4120:

"3.3.1.  Generation of KRB_TGS_REQ Message

    Before sending a request to the ticket-granting service, the client
    MUST determine in which realm the application server is believed to
    be registered.  ...

    If the client knows the service principal name and realm and it does
    not already possess a TGT for the appropriate realm, then one must be
    obtained.  This is first attempted by requesting a TGT for the
    destination realm from a Kerberos server for which the client
    possesses a TGT (by using the KRB_TGS_REQ message recursively).  The
    Kerberos server MAY return a TGT for the desired realm, in which case
    one can proceed.  Alternatively, the Kerberos server MAY return a TGT
    for a realm that is 'closer' to the desired realm ..."

And how does Windows work? It commonly simply poses TGS_REQ for server 
principal to KDC. KDC in turn is apparently allowed to return TGT for 
appropriate realm in reply. Windows recognizes that it's not exactly 
what it asked for, but a TGT for another realm, locates KDC for this 
another realm and resubmits TGS_REQ for server principal there. Or in 
other words conversation proceeds as following:

     client > "home" KDC     TGS_REQ(HTTP/server@HOME)
     client < "home" KDC     TGS_REP(krbtg/EXTRNL@HOME)
     client > "external" KDC TGS_REQ(HTTP/server@EXTRNL)

While compliant behavior would apparently be:

     client > "home" KDC     TGS_REQ(krbtgt/EXTRNL@HOME)
     client < "home" KDC     TGS_REP(krbtgt/EXTRNL@HOME)
     client > "external" KDC TGS_REQ(HTTP/server@EXTRNL)

Once again, the former is Windows-specific behavior, as Heimdal client 
fails to handle such relaxed replies from KDC. Heimdal KDC in turn can 
be trivially configured to play along with Windows by returning TGT to 
another realm in reply to request for an unresolvable service principal. 
And it does it for Windows clients only. The latter is achieved by 
examining the "name type" field and ensuring that it's NT-SRV-INST (see 
need_referral() in krb5tgs.c).

Then Microsoft has submitted referrals proposal to IETF (see 
http://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-referrals-09), 
which relies on client passing "canonicalize" bit in ticket requests.

All this is hardly any news, so why am I writing this? As/if the draft 
is approved things may start changing. It might pop up in Windows 2008, 
service packs, etc. Heimdal code is being/will be modified to adopt new 
standard. By this post I simply want to emphasize that backward 
compatibility is important to us and upcoming adaptation(s) should not 
break legacy behavior no matter how ugly it might appear. Thanks. A.