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

[Rick van Rein]

Hi Greg,

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

I worked really hard to weed out anything that might upset people, and the
result is really, really simple.  A preview is available on
http://tls-kdh.arpa2.net/spec/tls-kdh-ID.html
although that still mentions the now-gone RealmNameList and still assumes
that TXT is already defined in an RFC.

> tying it to global
> scaling of cross-realm Kerberos may be overly ambitious.

TLS-KDH will *not* dive into realm crossover yet, but wants to help prepare
for it.  To be honest, I was relying on the well-known TXT records in DNS,
thinking they might be used when protected by DNSSEC, and than discovered
that it never got standardised.

> We have been moving (kind of) in the direction of making the client's
> KDC responsible for service realm discovery, using referrals (RFC 6806).

Yay!  That’s the only sensible direction that I can think of :) to do it in
core infrastructure.

However, a spec shouldn’t carve that choice into stone I think; if a client
is locally configured to do this then perhaps we should not forbid it; so I
felt a need to write down a general story about TXT without mentioning
whether the client or KDC gets it.

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

None, provided that the negative response is authenticated.

> What is the current state of authenticating negative responses in DNSSEC?

It’s common practice, both on signers and validating resolvers.  And of course the
validation all the way down from the DNS root is widely available,

http://stats.research.icann.org/dns/tld_report/

There are two approaches for authenticated denial, NSEC and NSEC3, which only
differ in their ability to iterate over a zone’s contents.  Both are commonly supported.
Neither requires live signing with a secret key, since they span a range of DNS names
(NSEC) or hashes thereof (NSEC3).

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

I know, but I find that behaviour tricky.  A parent zone might implement a _kerberos
SRV record and take control of children who didn’t set one.  Remember we’ve also
seen * records appear in TLDs to redirect to advertisements.

With “what we’re doing now anyway” I meant that I doubt if anyone has a domain
setup with more levels of _kerberos TXT records than for the server name and the
zone apex.  Being forced to check all the intermediate levels seems like a waste
of computational power — especially under DNSSEC — and since the process
must be sequential (don’t continue until you’ve seen an authenticated negative)
it also costs valuable time.

-Rick