Re: choosing principal names

Harry,

On Wed, Oct 05, 2011 at 01:11:35PM -0500, Harry Coin wrote:
> code, is it too much to ask you publish consensus clear specific 
> principal naming guidance across OS adopters at least for the non-person 
> and system-admin actors?  Guideance that shows appreciation for present 
> concepts like 'root-as-a-box-specific-person-not-a-daemon-or-service', 

In my eyes one of the problems is that people have different and often
confusing ideas of what e.g. "root-as-a-box" means with relation to
Kerberos. So a recommendation how to name "that thing" is impossible.

> 'realm wide multihost service-xxx', 'box specific instance of 

What is a "realm wide" service?

> service/daemon/server', 'non-person clients of the aforementioned'.   

What is a "non-person client"? Is it a process? A host? A collection of
binaries and libraries acting together as an application?

A well-thought definitions, hard to misinterpret, would be necessary.

Think instead "how this principal is going to be used".
Which parties are going to to access its secret, talk to which parties,
and most important - how and by whom the name will be mapped to privileges.

> In the alternative, tomorrow will look alot like yesterday.

As the use of Kerberos becomes more widespread, people begin to notice
the problems caused by the bad traditions - like you did.

So it will change, but unfortunately the inertia is huge.

Given that there are two contradicting interpretations of principal names
(<user>/admin vs <service>/*), there is hardly a "recommendable practice"
which would not collide with recommendations from somewhere else.

In general there are extremely wide possibilities to choose the naming
depending on how much metainformation you want to put in the names.

A fully working scenario would be using sequentially incremented numbers
for naming all principals. Each service would have to have a mapping
table to properties which the service is interested in.

You might wish to instead use the same naming as some of the services
(like login service) do for their own purposes. This is the most common,
use of principals looking like Unix login names. This is also dangerous
as Unix account names vary between Unix hosts. Then they lose.

It is up to you how to combine this with certain Kerberos-aware
services which insist on interpreting the principals in a predefined way.
I guess "<string>/<domain>" is the form necessary for being able to use
GSSAPI with Kerberos.

[A different extreme compared to bare numbers would be to put a lot of
metainformation into the kerberos database, by using a complicated name
tree like

customer/cars/contract_2011-10-01/BobBobson/extra
print/test/bunny.example.net
...

Then you could carefully choose the beginning part of the names to "never"
collide with the "predefined" names needed by certain applications,
unless they clash with each other... A proper pam_krb5 could make name
mapping to Unix feasible.]

So at the end of the day it is the applications interpreting the principal
names which influence or dictate your naming. Different realms serve
different applications. No size fits all.

Cheers,
Rune