No mention of _kerberos TXT in RFCs / but we have DNSSEC now

[Greg Hudson]

On 10/13/2014 07:57 AM, Rick van Rein wrote:
> I’m finishing a TLS-with-krb5-and-DH proposal which relies on this record.  Without it, there is no chance of knowing how to crossover  to other realms (the mechanics of that being unsettled).  I may now have to introduce these TXT records in that specification.

Is this need associated with TLS itself, or with the specific use case
of HTTPS for cross-organizational web site access?  Gaining adoption for
krb5-authenticated TLS seems difficult by itself; tying it to global
scaling of cross-realm Kerberos may be overly ambitious.

We have been moving (kind of) in the direction of making the client's
KDC responsible for service realm discovery, using referrals (RFC 6806).
 Of course, the KDC then needs some way of doing discovery, so your
question still stands.

> Concerning *how* to use these records… I would prefer to not search as exhaustively as the draft proposes, but rather:
>  - first try at _kerberos.${SERVERNAME} TXT
>  - ignore unsigned responses
>  - is it absent (with signed NSEC or NSEC3)?  then pickup the zone apex from the SOA
>  - lookup _kerberos.${ZONEAPEX} TXT
>  - ignore unsigned responses
>  - permit multiple TXT records, each suggesting a realm name (or permit them combined in one TXT record)

How much of this fallback process can be manipulated by an attacker?
What is the current state of authenticating negative responses in DNSSEC?

> Moreover, it is probably in line with what we’re all doing now anyway.

The MIT krb5 implementation appears to try all domain parents; it
doesn't seem to take into account SOAs.