Re: choosing principal names

This possibly should go instead to some hypothetical wiki page?

I believe it is better to write here than to let it remain unsaid.

Things to have in mind while choosing principal names.
-----------------------------------------------------

There are three sides of the semantics of a principal:

1 an entity being able to prove that it knows the corresponding secret
  (this entity thus proves its identity, can possibly possess/prove
   multiple identities, even simultaneously, this is important)

  the entity needs the identity to get _access_ to services

  Examples of such entity:
   - processes of a certain uid on a Unix host:
     [the superuser can also (ab)use the identity but there is
     unfortunately no legitimate way for the superuser to fetch such
     identity even when desirable]

     can be named e.g. "bob", "alice", "staff/carol",
     "user/math/admin/eva", ...

     needs the identity e.g. to be able to login to certain hosts or
     make changes to a certain site's dhcp setup (authorization)

   - a host (the superuser in an OS instance)
     e.g. "host/alpha123.subdomain.example.net"
       or "alpha123/subdomain/example.net/hosts"...

     needs the identity e.g. to be able to access certain file systems
     where its configuration or some other OS-related data is stored
     (an important usage case even if hardly common)

2 an entity which needs to be able to verify others' identitites,
  to be able to evaluate authorization for them

  Examples:

   - a service (e.g. dhcp management over a custom protocol)
     e.g. "dhcpmanagement/europe.bigcompany.example.net"

3 the interpretation of the principal name by some entity named in (2),
  after the verification of the corresponding client identity
  (uzually used for taking decisions like authorization)

  Examples:
   - if the principal name is "bob" the client is allowed to manipulate
     the main power switch of the building
   - if the principal name is in a certain explicit list, allow
     creating objects in a database
   - if the principal name ends in "/admin", allow everything
     and so on

=> In other words, the technology and policies used for ACL management
   in different services may (and probably will) influence the choice
   of the look and of the hierarchy of the principal names.

   This holds despite the fact that Kerberos does not participate
   in authorization - the principal names do.

   /admin suffix for extra privileges at KDC is a usual practice, easily
   being percepted as a "more-trusted property of a principal". Beware,
   this can _not_ be assumed outside the actual context of ACL evaluation.
   "Trusted for dhcp" is not necessarily "trusted for mail filtering"
   or similar. Preferably use these principals for a single purpose
   (say KDC management) only. In general, do not let unrelated services
   use the same (implicit or explicit) ACL.

To make things less clear, a principal can be used both for (1) and
(2) but usually it is created and named with one certain usage in mind.
(Of course for mutual authentication the two functions always are used
together, but anyway normally with distinction of "service" vs "client")

Note that "serv_er_" / "client" spelling is actually misleading. A service
may be usefully represented by multiple servers/replicas sharing the same
Kerberos identity, the identity of the service.

There is a common confusion between (1) and (2) concerning hosts.
The login service(s) are often sharing a principal named "host/fqdn",
which is a misleading name, "host" is just the OS instance, not a
"service".

Moreover different services might and actually should use different
principals to isolate possible compromises to one service. It is only
due to Unix design that any "login-like" service must have superuser
privileges and is hard to be protected from if it ever becomes
compromised.  That's why it would not add a noticeable value to maintain
"login/xxxx", "sshd/xxxx", "telnetd/xxxx" and so on separately.

Note also the use of f.q.d.n. in principal names. Certain uses like
GSSAPI insist on principals being <somename>/<fqdn> where the fqdn of the
interface being used is to be checked against. That's unfortunate. The
actual idea is that the name shall reflect both the kind of the service
and the instance of the service. The instance is not necessary "the
service residing on this interface or host" but rather a "service domain"
(compare above "server" vs "service"). You see yet another example
of a confusion between different kinds of identities, this time in a
protocol design...

Hope this summary is useful.

Rune