'host' principals

[Theodore Tso]

On Mon, Jan 08, 2007 at 10:12:15PM -0500, Ken Hornstein wrote:
> I think most people would agree that "host" should be used for the
> traditional "logging into a remote system" type of things that Unix
> users are used to.  So, the common uses of "host" that I know about
> are Kerberos telnet, Kerberos rlogin/rsh, and ssh (Ken already
> described how ftp is an exception).

The reason why it was called "host" was because the possessor of that
service key would effectively have privileges equivalent to full TCB
on that host.  After all, in order to log in a remote user as root on
a Unix system, the process/daemon needs to have root privileges
itself.

So if you are creating some relatively one-off application that
requires root privileges (and so would have access to the /etc/keytab
file), it might make sense to just reuse the "host" name instead of
creating a new service name.  On the other hand, if you believe that
it's likely that you might to run as a separate permission level now
or in the future, it'd be a good idea to use a separate service name
from the beginning.

> In the case of SASL-ified
> protocols, this is part of a protocols SASL profile, and the protocol
> designer(s) pick that name.  So for POP we have "pop", for IMAP we
> have "imap", for SMTP AUTH we have "smtp", and so on.  So really, it's
> not application-specific, it's protocol-specific.

If I had designed things I probably would have used "mail" or "mbox"
for the POP and IMAP protocols, on the theory that if a mail server is
going to be doing both, there's no point creating separate service
principals for the two services, since they will both need the same
level of access in order to reference users' mailboxes.  On the other
hand, you probably don't have too many mail servers so the resulting
bloat to the KDC database is minimal, so it wouldn't be a big deal.

But naming has always been an area with a lot of personal opinions and
preferences, which is why standardizing anything involving naming is
almost about as hard as, say, building a global public key
infrastructure.  :-)

						- Ted