On Mon, 16 Nov 1998, Robert Watson wrote:

> Adding host key trust in the style of NFS is fairly easy to do -- it
> requires a few patches to the auth server to allow the acquisition of
> tokens for any vice id given that key; similarly, it would require
> modifications to clog to know how to do that, and then making clog setuid
> or setgid so that it could access a key cache on the client that normal
> users on the client could not access (that is, so that joe user would be
> automatically authenticated with joe-user-tokens, but could not retrieve
> system-administrator-tokens).  This would give you NFS-style trust of a
> particular host (or at least, a host with a particular key).  This is not
> a great thing, in that most people believe that the host-based trust model
> of NFS is upsetting inadequate.  On the other hand, it is very useful in
> the real world (such as in trusted environments, with ip filtering, etc).

Having written this, it occurs to me that there are a number of issues
that could be best addressed by alternative solutions, and how that is
handled could probably benefit from some discussion.  There are a few
possible goals I tried to address as a conglomerate that are perhaps
better looked at seperately.

1) There is a desire to have certain existing unattended processes
(presumably identified as distinct users, both in the local UNIX and Coda
senses) be able to function in an authenticated manner in Coda, without
modification.  Example: on a site's web server, not having to authenticate
and then reauthenticate in an attended (or loosely attended) manner.  No
doubt there exist many such applications, possible including document
retrieval systems, management of tertiary storage, some types of
databases, mail servers, etc.

2) There might be a desire to make the transition from an NFS-based site
configuration to a more powerful distributed file system such as Coda
without initially having to deal with integrating the token acquisition
process in a visible way to the user.  In such an environment (such as a
set of servers using NIS and NFS -- common, I believe, in Intranet-style
environments) a transparent changeover could be valuable.  This includes
the initial token retrieval, and then later the problem of tokens
expiring.

In the first case, an AFS-style 'reauth' solution would be acceptable.
That is, the key would either be entered at boot by an interactive user,
or stored in a local file.  The 'reauth' session would hang around
reauthenticating the user ad nauseum.  This is not hard to implement, but
clearly does not fill bill number 2 all that well.  On the other hand, it
is consistent with the coda security model.

As I see from your response (that arrived as I typed this :), the second
problems fits your case.  My feeling is that it would be nice to minimize
modification of the server side of things -- that is, to only modify the
auth server to add an IP-based or hostkey based trust relationship.  In
effect, that it could delegate the evaluation of the authentication to
entities with the key, and in return spit out (almost) any token asked
for.  I would handle this by adding a new identity/key to the auth
database (that could be authenticated to in the RPC call from clog), and
then a new RPC function called RetrieveTokenForUser that would accept as
an argument the viceid, and return a token much in the manner of the other
token retrieval calls that exist already.  It would presumably check that
the viceid was in a group of trusted ids (that is the authenticated
connection source) and could do this using the existing group database.
It would then determine if the requested tokens could be given out -- a
few approaches come to mind, including allowing members of a particular
group to have tokens acquired, or just allowing any but administrators, or
such.

This begins to address the problem -- it is now the case that a token for
any user can be retrieved by a trusted party.  The second problem is the
the decision to acquire these tokens, and their expiration, and I think
that has to be handled on the client.  Also of issue is how to get venus
to accept the tokens for the user.  The simplist answer that comes to mind
is a cron job running as root that takes as an argument, a list of
usernames and uids.  It proceeds acquire tokens for them all using the
host key, and then sequentially submits the tokens to Venus either by
calling setuid() to switch to the user, and then making the normal ioctl,
or we would add a new ioctl to Venus similar to the existing 'submit
tokens', except that it also took a uid.  Presumably it would verify that
the entity transferring the tokens was root.  Each time the cron job
occurred (presumably daily), all of the tokens would be acquired and
stuffed for the relevant users.  As I believe Venus has a fairly low
memory footprint for users and connections, this might scale quite well up
to some number of uid's (presumably around 50 or 100?  I have no idea --
no way to know without trying, or without doing the math :).

Other solutions that come to mind include a modification to the .login
script to run a setuid clog that performs the same actions, in essense,
and automatically starts up a modified reauth that reauthenticates as
described for solution (1) above, except using the host key.  The whole
setuid behavior prevents arbitrary non-root users from being able to
acquire any identity, instead limiting them to matching Coda identities.

If you already use a Kerberos in your environment, you can also use our
kerberos patches to pick up tokens.  Needless to say, they also expire. :)

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/