Concept Notes on TokenD
-----------------------

Token Daemons would constitute a userspace source of local privileged
token policy and enforcement.  The concept is simple -- a daemon that provides
token management services for other processes.  Some sample uses:

Login
-----

The user login process acquires a kerberos ticket (or has one transfered to
it via negotiation with a network source).  It now wishes to determine if a
local user exists for that ticket, and if so, acquire local credentials for
the user, and start processes for them.

Login contacts the token daemon, and provides the Kerberos ticket to the
daemon in the form of an appropriately formed token along with any
appropriate context information (login name, source host, etc).  The token
daemon evaluates this information, and if it likes the information, returns
a locally priveleged token with the user information.  This token may then
remain associated with any following user processes (as well as the kerberos
ticket in a token if desired).

Name Server
-----------

The name server is started by a normal local user or identity associated
with name service.  It now needs to bind port 53, but this is a reserved
server port on the local system.  It provides a reflection of its user 
tokens to the token daemon, and if the token daemon judges the results
fitting, sends back a local capability token allowing the binding of the
port.  Web servers might be similarly arranged.

Mechanisms
----------

The token daemon could listen on a local unix domain socket, and receive
requests + tokens via the socket.  Similarly, it could return tokens
and responses via that socket.

Login could make use of the newpag call along with deletetoken to remove any
privileged tokens it might have, and connect to the token daemon for the
purposes of presenting the kerberos ticket in return for the user token
providing continued service.

Token Caching
-------------

Tokend could provide token caching and long-term storage of keying and
capability tokens, as it would have extended rights for reading and
creating keys.

Restricting TokenD
------------------

It might be desirable to restrict the abilities of a TokenD via a set of
TokenD capability tokens that would be provided to various token daemons
at startup.  A particular capability token might allow the creation of
a particular type of tokens with the "Stamp of approval".  For example,
Inetd might be allowed to authorize the binding of low ports by daemons,
but not the overiding of filesystem permissions.  This might be implemented
as a specific major type (tokend), with minor types corresponding to the
major types processes in the PAG with the token might be able to create.
A group daemon might be able to provide only tokens associated with group
membership, for example.


$Id: tokend.txt,v 1.2 1998/06/26 13:17:30 robert Exp $
