On Tue, 31 Mar 1998 thoth_at_purplefrog.com wrote:

> > >   Precisely.  You create your own CA, install the cert on all the coda
> > > machines in the cluster, and then issue certificates for each server.
> > 
> > Why use a "CA" at all, under such circumstances?
> 
>   "Why use a hammer to pound a nail?"  The alternative is to copy the
> authorization keys around, because you can't have a certificate.

I still find the idea of using shared-secret oriented Coda Tokens as the
authentication mechanism to individual file servers/etc.  The cost of PK
on file servers is unecessary; performing a PK verification on each Bind
(given the lightweight use of binds all over the place) seems unfortunate.
Rather, I would make use of a certificate/PK operation at the time of
authentication to the auth server -- depending on the security model used,
the organization could scale up their auth servers without loading the
file servers.  There are advantages and disadvantages to the current token
scheme -- one of the disadvantages is that a single key is used between
the auth servers and the file servers.  I'd rather see a key used between
the auth servers and individual file servers.  This would use the auth
server more as a KDC kerberos-style.

This again raises the issue of moving to kerberos as a replacement auth
system -- and again raises my objection that I don't want to tie us too
closely to a kerberos system.  For now, until the authentication model(s) 
of choice become more clear, I'd like to stick with the current-day token
system.  As part of my work with Peter, I have restructured the RPC2 bind
a bit to support more general authentication systems -- fixing the token
code will at some point become fairly straightforward.

Keeping certificate behavior on the auth servers would allow the auth
servers to become the single repository for authentication
rules/information mapping to Coda identities rather than placing them on
each file server also.  File servers should, in my view, perform
authorization/authentication actions only based on a coda identity
established by the auth servers.  This is consistent with the current
implementation. :)

  Robert N Watson 

Carnegie Mellon University http://www.cmu.edu/
SafePort Network Services  http://www.safeport.com/
robert@fledge.watson.org   http://www.watson.org/~robert/