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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos