> 
> Also, can someone comment on my earlier feasability questions please? ;)
> 

Whoops. I'll comment, and as usual you'll find a lot of the kind of
comment: "too much work for now" in my comments.


> > >1) use Kerberos as the authentication/encryption mechanism all the way
> > >though Coda? (This might be a way to get around encryption export stuff,
> > >since krb5 can be gotten from replay.com and there is a free krb4 clone in
> > >Europe somewhere)

If someone has time to make binding an RPC2 subsystem, i.e. bindings are
ordinary rpc's which do priviliged things in the rpc2 data structures,
then this is feasible.  [But we won't have time to do it here!!]  The Coda
packet filters are already implemented in this way (see coda-src/fail).

We do want to keep our "Coda handshake" so that working versions of Coda
do not require people to first get Kerberos going, since on Windows for
example, this might be very hard.  But both could be subsystems.

> > >
> > >2) make direct use of kerberos principals so that say, anyone with a
> > >joeuser/admin principal can be a member of the System:Adminstrators group
> > >while the regular joeuser principal is not. (along these lines, this would
> > >allow a joeuser/cron or joeuser/daemon principal to get coda tokens for
> > >cron jobs or such from a kerberos ticket the user has left for that
> > >purpose, via a ticket with an extremely long lifetime)
> > >This might also solve the "how do I authenticate the web server" type
> > >problems. (Correct me if I'm wrong, but could having a host key/principal
> > >for the webserver machine allow this?)

Yes.  Coda 5.2 will have a new [simple] protection database, that could
become the foundation for this.

> > >
> > >3)
> > >   a) automatically get coda tokens from kerberos tickets if they exist
> > >       or

Yes, but it would require changes to the cache manager to detect that
tokens are missing, and try to aquire them.  This is not always desirable,
because tokens would be obtained rather spontaneously, whenever Venus
starts to fetch something, perhaps the user doesn't want that.


> > >   b) use kerberos facilities to replace coda tokens (this sorta goes with
> > >      (1) above)
> > >
> > >4) This is more of a kerberos thing, but krb5 has the DES3 code
> > >   modularized, so what would it take to update the krb5 encryption code
> > >   to use something like blowfish and friends?
> > >

Probably Robert knows all about that.

- Peter -


> > >
> > >On Sun, 7 Feb 1999, Robert Watson wrote:
> 
> -- 
> Troy Benjegerdes		troybenj_at_scl.ameslab.gov
> Scalable Computing Lab		   hozer_at_drgw.net
>