Re: choosing principal names

On Wed, Oct 5, 2011 at 3:27 PM, Harry Coin <[email protected]> wrote:
> On 10/5/2011 3:00 PM, Nico Williams wrote:
>>
>>  Each application should document
>> its principal naming requirements.

Here I was speaking of service principals.  With regards to client
principal naming, see below.

The point is that LDAP is responsible for documenting that the service
name to use for it is "ldap".

Incidentally, there's an IANA registry of GSS hostbased service names.
 It's hardly used by anyone.  Instead third parties either camp on
service names, use IANA service names from the port registry, or make
their service names configurable.

> And so kick the can into the laps of the users: for each application they
> might now or in the future use:  to learn this whole obscure world, and how
> their proposed applications make use of it.  This innocuous sentence of

Again, for an application that conforms to the GSS model, the user
(admin) ought to have control over client principal naming because
authorization should be name-based [and configurable].  Naming
extensions does not change this, except in so far as it makes
authorization easier for some applications.

It might be nice to standardize some authorization interfaces, but
there's enough OS-specific details there to make standardization
challenging.

> yours if full stop, makes it the end user's job to decide whether the
> documentation applications provide does or does enshrine naming policies
> that might or might not collide with current and unspecified future
> applications that might or might not use gssapi or other middleware a few
> layers and two daemons down from where they live.    And if there are
> collisions, do the applications provide ways to mangle default config files
> beyond all recognition and so be obliged to maintain them forever, learning
> sasl_auth rewrite rule formats and other utterly avoidable minutiae or only
> if 'untainted on this os' ?

Sysadmins are responsible for preventing collisions within the spaces
they administer.  There's IANA registries for service naming.  And so
on.

> Kindly reconsider.  Just name space guidance that will if followed
> disabiguate people from non-people, services from instances, clients from
> servers and manage the grey area of 'root real user'.

Don't you think we're basically in agreement?  I do.

The problem is not what you and I think the world should be like, but,
rather, that people have made mistakes.

Solaris' Secure NFS stack uses a client principal naming convention
for root-equivalent access that's rather quite obnoxious -- I consider
that a bug.

Microsoft SQL server uses a naming convention where ":<port-number>"
gets tacked on to the _hostname_ component of what would otherwise
look very much like a host-based service principal name.  (!!!)

The thing to do about these problems is to file bug reports with the
vendors.  Indeed, in this case, any discrepancy between major NFS
server vendors regarding client principal naming would be a great
reason for those vendors to want to fix this by... doing the right
thing (described above).

(You might ask why I didn't get the root-equiv issue fixed in Solaris,
but I did get the need for any system principals for automounting
removed, which makes a huge difference for things like laptops.  I
didn't fix every problem I ever stumbled across as that was not always
my job, and not every bug filed gets enough attention.)

Nico
--