[571] in Kerberos-V5-bugs
Re: More Concerns Over The Case of The Realm Names
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sat Jul 9 09:23:06 1994
Date: Sat, 9 Jul 94 09:22:44 EDT
From: tytso@MIT.EDU (Theodore Ts'o)
To: John Gilmore <gnu@cygnus.com>
Cc: "Doug Engert" <DEEngert@anl.gov>, auth-pilot@es.net, bcn@ISI.EDU,
krb5-bugs@MIT.EDU, gnu@cygnus.com
In-Reply-To: John Gilmore's message of Fri, 08 Jul 1994 17:09:29 -0700,
<199407090009.RAA04839@cygnus.com>
994 17:09:29 -0700
Date: Fri, 08 Jul 1994 17:09:29 -0700
From: John Gilmore <gnu@cygnus.com>
Cygnus provided Kerberos support to the Usenix terminal room for the
last two conferences. The most common problem encountered at Winter
Usenix (when I was there) was that peoples' realm names were in the
wrong case.
Funny, I provided the Kerberos support to the IETF terminal room at the
last IETF meeting; and we didn't have this problem.....
The second most common terminal-room problem was that peoples' realm
names were not in the *%^*&&$## ascii text file ""database"". After
we get the realm name problem resolved, it'll be time to define a
standard way to put host->realm and realm->kdc mappings into the DNS.
.... of course, the way I solved this problem was that if you weren't in
the krb.conf file, I had my "krlogin" program create reasonable defaults
for the Kerberos server and the Kerberos realm (which the user could
accept by typing return, or could override by typing the correct realm
name). The reasonable default for the realm name was the domain name,
uppercased, using the established convention for the "host->realm"
mapping. Funny, that caused 99.7% of the users to not need to type
their realm name at all, so they didn't need to get it in the right
case.
There's no reason to panic or flame over this stuff, it's the usual
result of a user interface designed by programmers. It gets a lot
more obvious what to improve, after you see some naive users stumble
on the same things time after time. (And at Usenix, these are naive
*Unix wizards*!!!)
You're right, you can do an awful lot by improving the UI. Because of
the existence of an established convention, it was very easy to make the
IETF "krlogin" to do the right thing with defaults. This is one of the
reasons why I don't want to change the convention, since there are
already sites using uppercase realm names, and it would be extremely
difficult to have a site change realm names --- especially if they need
retain V4 compatibility.
Is there a good reason that realm names are defined to be
case-sensitive? We could avoid the entire debate by simply making
them case-insensitive, like host names or email addresses. (This has
a few problems in non-English alphabets, but with proper use of
toupper/tolower rather than "x^040", it is solvable.)
Heh. Actually, email addresses are not case-insensitive; they happen to
be, under Unix, but if you look at the RFC's, the host-independent
portion of the email address is specified to be case-sensitive. The
only exception to this rule is "postmaster"; "Postmaster",
"POSTMASTER", and "PoStMaStEr" must all go to someone responsible for
the mail system. Other than that, mailers are allowed to parse the
portion of the email address before the "@" sign in a case-sensitive
way. Some systems, like Multics, which had case sensitive usernames,
actually had to do so.
That results in the problem for Kerberos --- even if we make the realm
to be case-insensitive, the rest of the principal name has to be
case-sensitive. And, the way many programs check authorization is to
unparse the Kerberos name into a Kerberos principal, and then do a
string compare. (This method is actually strongly allowed and suggested
by the GSSAPI, since it is the most efficient; otherwise, each term in
the ACL has to be parsed into the internal format, only to be comparsed
and then freed.) However, if part of the Kerberos principal is now
case-independent, you won't be able to do a simple string compare any
more.
The best you could do is to have the unparse routine always return a
certain cannonical form for the ASCII version of the principal name ---
say, with the realm all in uppercase. But that means that while
everywhere else in the system, realm names would be case insensitive,
but the ACL list would have to entered with the realm names in a certain
case convention.
Furthermore, one way string to key transformation currently folds in the
realm name in a case-sensitived fashion. Any change which touches on
this would also have to cause the string to key algorithm to change the
realm name to some cannonical form first. And, this would almost
certainly force realms to rekey their databases. (*)
Finally, the Kerberos database is currently indexed on the entire
principal name so once again the realm name would have to be forced to a
canonical form before a Kerberos database entry could be looked up.
The bottom line is that in order to make realm names case-insensitive,
we'd have to put hacks all over the Kerberos system to force realm names to a
certain convention anyway; why not simply have the UI present the realm
names according to the already established convention? This will do
mostly the right thing. The only reason why I don't suggest that the UI
always forces the realm name to upper case is because OSF decided to
adopt an opposite convention. But in most cases, users don't need to
type the realm name at all --- that's the purpose of the krb.realms
file. (**) The only exception to that is programs like the IETF or
Usenix terminal room programs, and there are ways you can deal with that
using intelligent defaulting rules. Heck, if you want to support the
OSF DCE convention, just have the program try both and see what works.
- Ted
(*) There is the beginnings of support in the Kerberos database to
allow a site to change their realm name without forcing everyone to
march in front of an accounts administrator and set a new password.
This support could be used to allow sites to change to a new convention;
however, it is not complete yet, and it still doesn't address the issue
of changing names on access control lists all over the site's systems.
(**) While having a DNS secured mapping for the host->realm function is
convenient, note that this does cause a potential security hole if
you're concerned about mutual authentication. Namely, a user could be
trying to connect to a foreign host, and the DNS request could be
spoofed so that the client gets the wrong realm; if the TCP connection
is also then spoofed to a host under the control of an rogue Kerberos
administrator, a client could potentially be talking to the wrong host
without even knowing it. This can be somewhat fixed if the Kerberos
realm which was actually used is presented to the user, but this assumes
that the user will be paying attention.
BTW, I have been informed that at least one person in the U.K. has a
program that will spoof DNS INADDR requests, so that a given IP address
can appear to have a hostname like NOT.REALLY.IN.THE.US --- the reason?
To get around ftp servers that try to restrict transfers in the name of
export control. So to posit the existence of programs to spoof a DNS
host->realm mapping is not all that unreaseonable.
