Spurious tickets when using DNS realm configuration (and cross realm TGT)

[Greg Hudson]

On 7/28/19 6:49 PM, david at crossfamilyweb.com wrote:
> Ok.. so I made a bunch of changes to the krb5.conf on the kdc to remove
> the default realm as well as to add in the other realms, additionally I
> added 'dns_lookup_realm' and 'dns_lookup_kdc' to the krb5.conf on the
> client machine as well as the kdc, and now I see the intermedate tgts in
> all cases.   So its definitely config driven, and things appear to be
> setup correctly; I wish I understood the subtleties of these behaviors
> more (was it removing the default_realm?  was it the DNS entries? adding
> the remaining realms?)

Some of the design principles behind referrals may be under-documented.

Using unauthenticated DNS for locating KDCs is not an attack vector, as
it is no less secure than the network path to the KDC itself, and the
protocol is designed to expect attacks along that path.  So it is on by
default.

Using unauthenticated DNS for host-to-realm mapping can be an attack
vector, because the mapping affects who you authenticate to.  So using
TXT records for this mapping has to be explicitly turned on, and even if
it is turned on, we try to get a referral from the local KDC first.
When possible, using referrals is recommended over using TXT records.

As a loose rule, we only cache what we ask for.  If the client does
cross-realm using referrals, it doesn't cache the referral TGT (as of
release 1.16, see [1]) because it asked the local KDC for a service
ticket, not a cross-realm TGT.  But if the client authoritatively knows
the realm in advance (typically via [domain_realm]), it explicitly asks
for a cross-realm TGT, and caches it.

[1] https://krbdev.mit.edu/rt/Ticket/Display.html?id=8579