Quoth Marc Horowitz <[EMAIL PROTECTED]>:
| "Donn Cave" <[EMAIL PROTECTED]> writes:
|>> I seem to be too dense this morning to see how service principal
|>> names could be authorization. I mean, with client principals it's
|>> obvious enough, but I reckon that the service would be the one who
|>> grants authorization, not the one who receives it, in at least the
|>> typical use of service principals.
|
| There is an implicit authorization of the server to the client, or
| else mutual authentication would have no use. If I'm printing company
| financials, I want to be very sure that the entity I'm talking to is
| the correct printer. The authentication comes from mutual
| authentication, and the authorization is implicit in the user ("Should
| I print to the printer in the CFO's locked office, or the one in the
| reception area?").
Well, OK. The way I see it, the authorization you're describing
is separate from authentication. Authorization is naturally tied
to identity, and the fact that identity is established via authentication
doesn't need to mean that we have a problem with authorization by
authentication.
But it's true that this authentication is made available in a more
or less arbitrary way to system processes - it isn't like they have
any natural identity - and the purpose is to confer authorization on
them. QED. But not really germaine, in my opinion, as we have the
same arbitrary system however we name the principals, hence my question:
| >> By extension, do you see any reason why all services should not just
| >> use the "host" principal? That's not a sarcastic question - I think
| >> the point could be argued, at least for services that all run as root
| >> or have enough common privilege.
|
| Yes, there is a reason. As several people have said, not all services
| are tied to hosts. For example, afs uses the principal name
| afs/cellname@REALM to authenticate. This is important, as the client
| does not know in advance what host it is getting the data from; in the
| case of replicated data, the file server host can change on the fly
| without userspace ever being aware of it. Another example is the
| krbtgt service; the instance there is the kerberos realm, not the
| kerberos server host.
|
| Also, since service principal names need to be defined in advance, you
| want fine-grained naming because you don't want to require that a
| particular service with root privileges. Just because server X does
| so today doesn't mean there won't be a different implementation
| tomorrow which runs as a separate user.
|
| Sadly, it looks like LDAP uses the hostname of the server, which is
| probably not what you really want.
You're thinking that the principal name should be "ldap", and the
particular database the instance, like "ldap/sendmail"? Interesting
idea (though probably somewhat at odds with how GSSAPI handles service
principal names.) I would have modified the service part, and left
the host there per normal service principal convention - like
"ldapsendmail/y.z.edu" - but I can't say why it would be better in
any practical way.
Donn Cave, [EMAIL PROTECTED]
