Re: [kitten] Finding Kerberos Realm Descriptors in secure DNS

[Nico Williams <[e-mail]>]

On Thu, Sep 17, 2015 at 09:45:56AM +0200, Rick van Rein wrote:
> 5. The current implementation of TXT does not take DNSSEC into account,
> meaning that its existence is not going to be of as much use as we'd
> like to think.  IOW, we'd still be imposing restrictions on KDCs,
> probably in terms of their default settings.

Well, no, the client can and should onlye use TXT RRs for this that have
been validated.  One could use TLSA RRs without DNSSEC -- it makes
little sense, but the point is that the same is true for TXT RRs for
host-to-realm lookups.

> 6. As for i18n, we might use DNS' approach for it and let Kerberos
> simply use the xn-- names internally.  I cannot imagine that this would

This... is a large subject that we should not broach in this context.

That said (heh) I think the right answer is to consider DOMAIN-style
realm names as having multiple alias forms such that a) they are
case-insensitive (at least as to ASCII labels), b) A-labels are aliases
of the corresponding U-labels.  Clients and services should internally
canonicalize to up-cased Unicode forms wherever possible (with
configurable exceptions, as there are ASCII lower-case realm names in
production use) for name-based authorization compatibility reasons.
Finally, we can then either bite the KerberosString bullet or leave it
for later by using A-labels in KerberosString domainname slots.

> 7. Something I don't know is whether and how the KDC distinguishes realm
> name styles.  In the above I've assumed that it is tagged, and that end

By the presence/absence of ':' in the name.  No realm-type value is
explicitly encoded in any Kerberos PDU.

> user tools also get to see these tags.  If not, there might be a few
> more problems lurking, and things to configure manually, with sane defaults.

No problems lurk here, thankfully.

> I suppose KREALM is hereby history, so we would be making a choice
> between TXT and PTR.  My vote is now on PTR, with the aforementioned
> implications of i18n and making the KDC look at the realm's naming style
> before it decides how to compare (or have per-realm configurable
> comparison rules).  The break with implemented but never-standardised
> TXT records is IMHO warranted because we are relying on DNSSEC which is
> an extra responsibility for the KDC that goes beyond TXT anyway.

TXT to Informational.  PTR to Proposed Standard.  That's my preference.

Nico
--