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

[Rick van Rein <[e-mail]>]

Hey,

I'm also moving over to the TXT-or-PTR side of things.  The middle boxes
are a concern and I'm hoping that one day clients will be able to do all
this; middle boxes will be quicker to pass DNSSEC than to pass KREALM.

1. In essence, the value added by my proposal is the use of DNSSEC, not
the KREALM RRtype per se.  The _kerberos prefix takes away my anxiety
over accidental interpretation of a PTR record as a Kerberos pointer and
potential security threats that this might have caused.

2. TXT can hold multiple <character-string> entries, but each has a
length of up to 255 characters for the infix-dot notation, and DNS names
in "length, label, ... zerolength" notation can reach up to 255 bytes. 
As far as I can see, this leads to infix-dot domains of up to 254
characters, so we can constrain our use of TXT to one such
<character-string> of up to 254 chars without constraining the size of a
stored domain name, thus avoiding interpretation / comparison /
buffer-overflow problems.

3. PTR limits our use cases to domain-style realm names.  This is not a
problem to me, as I'm mainly interested in DNS-based realm crossover for
which the other / older forms are not going to work anyway.  But I do
see that TXT will support the older / other domain styles as well.

4. PTR can mangle case, although it doesn't always do it.  Since we are
limiting to domain-style realm names, there can be two ways out exist,
and their benefits can be stacked up to achieve benefits for the
flexible party:
   4a. Permit the KDC to use case-insensitive comparisons; more
generally, let it use the name-style to figure out what to do; X.509
attributes have their own case comparison and DNS does, too.  The latter
would give us case-insensitive comparisons.  If AD already does this,
then so much the better.  (I never considered to propose such major
changes!)
   4b. Permit the client to map the PTR outcome to uppercase, and
thereby match with 99% of the realms, even if the KDC is not supportive
of case mapping.

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.

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
lead to different treatment of the names in the KDC.  As for end-user
tools, we could modify them to understand DNS i18n and print these names
in UTF-8.  Mindful of the potential problem of foreign-alphabet
lookalikes as we've also seen in URLs, we may not always be able to cope
with it by printing in multiple colours as was done for URLs, but in
case of mixed language subsets we might fall back to printing the xn--
style of names, clearly signalling to our users that something is the
matter.  In that notation, everyone can tell the difference between two
names.  This DNS-style use of i18n would be possible immediately and it
is easier to use with PTR than with TXT, since tools will interpret the
<domain-name> in PTR and not the <character-string> in TXT.

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

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.

-Rick