Subject: the realm-name case issue

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 16 Apr 2000 00:22:29 -0700 (PDT)

Here's what I suggest regarding realm names and case.  New language
for kerberos-revisions is at the end.  I really don't care about the
case-insensitivity issues except to the extent that they are wrongly
mixed up with the issue I do care about, which is not having my
installation's realm name declared non-compliant.

I think there are three separate (though related) design decisions:

  (1) What is the acceptable character set for DNS-based realm names?
      Possibilities include: upper-case only; all characters permitted
      in DNS host names (per RFC 952: a-zA-Z0-9-, "." only as element
      separator); or all characters supported in DNS labels in general
      (any data, only limited by length); or some other set.

  (2) If mixed case realm names are supported in (1), does the
      DNS-based configuration scheme (being defined in
      draft-ietf-cat-krb-dns-locate-*) have to support the use of
      distinct realms whose names match via a case-insensitive
      comparison (eg, "Example.Com" and "EXAMPLE.COM" as distinct
      realms)?  Or, is it acceptable to say: setting up two or more
      realms whose names differ only by case produces undefined
      results, when using this configuration scheme?

  (3) Should there be support in client and server implementations,
      and in the protocol if necessary, for case-insensitive matching
      of realm names in all places where realm names are compared?

These issues seem to get jumbled up in discussion (including in my own
previous comments, I'll admit).  I suggest that if issue (1) can be
separated from the others it can be decided in a reasonable way while 
while we go on debating the UI issues in (3) till we're exhausted.

Regarding (1), we know these things:

  (a) a fundamental constraint is that the realm name is used in the
  crypto, so to do a successful ticket request a client must know the
  case-exact realm name string;

  (b) RFC 1510 says that realm names are GeneralStrings, hence any
  character (except NUL), but conventions apply to particular uses, eg
  domain names;

  (c) the upper-case-only convention has been promoted by the MIT
  implementation for a long time, and most sites do that; 

  (d) some (no one knows how many, but more than a handful) sites that
  use domain-name-based realms use lower- or mixed-case realm names;

  (e) kerberos-revisions-05 proposes to make the upper-case convention
  a MUST (section 7.1:  "Domain names must be converted to upper case
  when used as realm names").

Now, what is the reasoning behind the proposed all-upper-case realm
name rule?  As far as I can tell it is this:

  (i) there are times when a client has to derive a realm name from a
      DNS name (eg to use a kerberized service on a host, or to
      construct an inter-realm path), because it has no explicit info
      mapping that DNS name to a realm name;

  (ii) in these cases the client needs to derive the exact
      (case-correct) realm name;

  (iii) so, this DNS-to-realm derivation must use a simple rule with a
      deterministic result, and convert-to-upper-case is the
      arbitrarily chosen simple rule;

  (iv) hence DNS-based realm names must always be upper case so that
      this rule will work.

The MIT Kerb5 admin documentation says, regarding the domain_realm
section of the krb5.conf file:

  The [domain_realm] section provides a translation from a domain name
  or hostname to a Kerberos realm name. The tag name can be a host
  name, or a domain name, where domain names are indicated by a prefix
  of a period (`.'). The value of the relation is the Kerberos realm
  name for that particular host or domain. Host names and domain names
  should be in lower case.

  If no translation entry applies, the host's realm is considered to
  be the hostname's domain portion converted to upper case.

(I assume that equivalent configuration functionality is provided in
other implementations.)

Now if the client finds an applicable translation entry, it uses the
realm name exactly as found there; so upper-, lower-, and mixed-case
realm names can be used in this case.  (Doing host->realm translation
via DNS TXT record lookup also works fine with non-upper-case realms,
as we have demonstrated here.)  So in this, the normal case,
non-upper-case realms present no problem at all.

If there is no translation available, then the DNS name is converted
to upper case as described.  But what does the client *do* with the
realm name that it has just derived?  The only reason I can think of
to do this derivation is to contact (ultimately, perhaps via
intermediate KDCs) a KDC for the derived realm to obtain a service
ticket.  To do this, the client has to have configuration info
available to it about that realm, in particular the realm's KDCs; and
if there is configuration info available for the realm, that info
includes (or should include) the case-exact spelling of the realm
name.  If the client is using the traditional config file to get KDC
info, then obviously the exact realm name is there.  If the client is
using the dns-locate method to find KDCs, then there's no reason it
can't use DNS to find the exact realm name spelling too (we'll have to
define this, and we should).  Any other realm-config-data method
should do the same.

So in the supposed cases where the converted-to-upper-case
derived realm name is needed, it is in fact *not* needed, because
either the proper name of the realm is available, or the realm is
unknown and hence the derived name is useless.

If someone can present a practical case where the derived realm name
is actually useful, I would love to understand it.

(Let me note here that there is IMHO an important difference between
(a) the operation of mapping a DNS domain name -- which is inherently
case-insensitive -- into a realm name, an operation that simply has to
be done in some circumstances; and (b) the idea of handling purported
realm name strings themselves (as typed in a kinit command, say, or
found in an ACL entry) in a case-insensitive manner, which is an
*optional* thing to do as a convenience to the user.)

Now it may be the case that some sites are using krb5.conf files (or
their equivalent) that do provide realm config info, but don't provide
domain->realm mapping info, and hence rely on the current
name-derivation scheme to generate realm names, which realm names
would currently have to be all upper-case.  This is fine (though a bit
odd), but surely isn't any reason why *other* sites can't have
non-upper-case realm names.  I suggest that these sites would be
better-served by using the dns-locate method to deliver the exact
realm name to the client, or by a more flexible realm-name-derivation
algorithm that takes the input domain name, searches
case-insensitively for a match for it among the set of known realms,
and uses the exact realm string if found; either of these would allow
non-upper case realm names to work.  (But I wouldn't force them to use
these better methods, either.)

It may be that another argument for the upper-case-only rule is more
UI-oriented, namely that if users always see realm names in upper
case, they'll be more likely to get them typed right; whereas if they
see lower- and mixed-case realms too they'll think that realms are
inherently case-insensitive and will be confused.  I don't see that
this argument has enough weight to make upper-case-only be a MUST.

So, in the absence of evidence to the contrary, I conclude:  that the
upper-case convention, however venerable, is completely unnecessary
(in fact it's bad if it makes client-writers assume that realm names
will always be upper-case); that realms using upper-, lower-, and
mixed-case are all equally acceptable; and that implementations should
be encouraged to support all of them equally.  I propose that language
to this effect be added to kerberos-revisions in the section about
domain-style realm names; possible language is below, also fixing
other problems with the current language.

Regarding design decision (2) above, I think it is reasonable to say
that defining distinct realms that differ only by case is an unusual
thing to do, so the dns-locate method doesn't need to support it by
defining some awkward means to represent case-specific names.

Arguments about (3), the case-insensitive handling of realm names in
general, can proceed independently ...

 - RL "Bob"

---

Proposed new language for section 7.1 of kerberos-revisions:

          domain:   ATHENA.MIT.EDU (example)
            X500:   C=US/O=OSF (example)
           other:   NAMETYPE:rest/of.name=without-restrictions (example)
        reserved:   reserved, but will not conflict with above

     Domain-name-style realm names are based on the string form of DNS
     names [Moc87].  They consist of components separated by dots
     (".").  A component may not contain a dot, a colon (":") or a
     slash ("/").  Names may contain upper-case or lower-case letters,
     but defining distinct domain-name-style realm names that differ
     only by case (e.g., "Example.Com" and "EXAMPLE.COM") may produce
     undefined results.

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]