Re: choosing principal names

On 10/6/2011 6:14 AM, [email protected] wrote:
> 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.

That ship sailed when you required principal name space collision == 
bad, and packages that use kerberos independently maintainable == 
good.   Denial just obstructs wider deployment, which of course might be 
acceptable in the name of the status quo for those who've made the 
investment in 'understanding everything from device driver mutexes to 
screen-savers'.   How many are willing to pay that price?

I think it is worth the effort to identify the major distinctions folk 
have in these 'foggy arenas', give them names, and then treat them 
correctly.    I suggest 'root' and its Redmond equivalent 
'Administrator' be understood as it's own named category-- principal 
names that are incomplete if not including a hostname, understood to be 
persons, not necessarily the same if only the name or only the hostname 
match.   Another for 'instance of non person off-box service providers 
with total local authority (to include peer-to-peer)' (host).  Another 
for 'previous except not off-box service providor instance' (nslcd run 
as root).  Duplicate the last two except 'limited authority' (e.g. 
ldap).   Another for 'authenticated client of named possibly multihosted 
(sub)service' (e.g. to public parts of replicated ldap directories on 
open access kiosks).   And last- 'persons in their various user and 
administrative instances whichever box they might be using'.

Aware of the present understandable sentiment to push the foregoing off 
into the realm of post authentication 'authorization', while workable it 
is not to be preferred as such tends to block multi-os installation 
interoperability.  Authorization has a major part of its function to be 
much closer to the nature of each application as it relates to its own 
host os.


>
>> 'realm wide multihost service-xxx', 'box specific instance of
> What is a "realm wide" service?
E.G. in a building we have, among other things, open access kiosks and 
boxes.  We wish to create a principal to be recognized by any of the 
replicated directory offering servers (any one of which might or might 
not be operating at any moment, managed by a load balancing device).  We 
don't want to allow anyone managing to hack into the wifi access.  We 
don't want to create a principal for every one of those boxes, we don't 
even want to give them names, just whatnot out of a dhcp pool.  We are 
willing to burn a unique keytab into their eproms that changes every 
week during routine cleaning.

>
>> 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.

I'm impressed by your clarity in thinking and do believe you and the 
others here are quite up to the task.  Though not such an easy one.


> 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.

It won't change without guidance from here, since only from here can the 
various application and OS authors look as a common point of reference 
in principal name organization.   Otherwise each will be Balkanized.    
If you provide some guidance here, then those who which to be 'islands' 
can do so, but it is a choice, not a requirement.

The whole point is to make secure interoperability a possibility without 
forcing all the packages to be maintained together and having one person 
comprehend  the kerberos namespace collision issue and whack-ho upon the 
applications until they conform.

There is, of course, the big unspoken alternative.   Every application 
gets its own kerberos realm.   However, you have already allowed the 
defacto guidance to establish itself that realm = domain name in caps.   
So, that ship has sailed too.



> 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.

You mean it is up to me to choose from among those applications that 
have decided to follow a convention not in conflict with one another.  
Or, in the alternative, patch them until they allow me to specify such 
names as I prefer.   Thus kicking the can into the end user camp.   Well 
and good, if you are prepared to limit acceptance by high barriers to 
scaled use.





> [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.

Thanks for the care in your thoughts.    Indeed all would be well if 
kerberos hadn't allowed the defacto standard of realm==domain name in 
caps to establish itself.  Being that ship has sailed, and kerberos has 
required no name space principal collisions, guidance to application 
authors as to how to format principal names to suggest the various 
categories aforementioned would reduce barriers to acceptance and scale.

Regards to all,
Harry