🚀 go-pugleaf

> I propose allocating a flag bit in the KDC database to indicate that
> the indicated principal is not allowed to provide direct service, i.e.
> the TGS will reject any requests to issue a ticket which the principal
> can decrypt.

I presume that the new restriction would be that Kerberos would reject
all requests by A to be authenticated to B where B is flagged as a
user.  The only way to get any data encrypted in B's password would be
by claiming to be B and asking for authentication to some (real) service.

The proposal seems weird, because it seems to be more or less
equivalent to a bald statement that "there is no need for direct
user-to-user authentication".  Does anyone believe that?  Or can it be
demonstrated the proposal is not equivalent to that statement?

I also worry that it might interfere with another need that we don't
have much experience in meeting.  A user with a private workstation
needs to be able to provide authenticable services--a private data
service, or maybe just NFS export of a private file system.  At the
moment, although the capability is residual within Kerberos, we don't
have any good way to administer authentication for a privately
delivered service.  The proposals to replace the xhost crock also open
some of the same issues.

There are a couple of ideas kicking around, including a suggestion I
made recently about user-created subsidiary principals.  Perhaps if we
could bring one or more of those user-provided service ideas into a
complete scenario, then it would be clear whether or not there is any
interference between meeting the requirement of authenticating
user-provided services and the idea of distinguishing users from
services.

					Jerry