> NFS is cheese.

So, let us forget about it.

> AFS RPCs are authenticated but not encrypted.

They could be, rxkad has support for it. Don't know what tramsarc does in the
US version ? In the ``international'' version they do only encrypt the rx headers.

> DFS
> uses the exact same game, except every fileserver has its own
> principal, therefore, the kernel has to store an authenticator for you
> for every fileserver machine that you contact. i.e:
> 	
> 	/.../mycell.edu/hosts/fooserver1/dfs-server
> 	/.../mycell.edu/hosts/physics/dfs-server

This could be done by an Free AFSClient/server, too. There may be plan for
such a beast.

> Whatever Coda's RPC uses simply needs to establish a shared secret
> key between the Coda client and the fileserver. MD5 the RPC payload,
> encrypt the MD5 with the shared secret key (perhaps some time-stamps
> or nonces to thwart skilled code-breakers).  Stuff it to the wire: you have
> packet privacy. 

While someone hacks some security in the protocol, do it right from the
begining and throw encrypting one the whole thing... Dont try to satify ITAR
or something that stupid, ie this work has to be done outside the free country.


> Ultimately, you have to have the crypto stuff in the kernel to seal/unseal
> the RPCs. You have to have a way to let user-land processes stuff their
> authentication credentials into the kernel so the secure RPC layer
> can use the keys to cipher the traffic streams on behalf of the users
> request.

That you need to have cryptostuff in kernel i dont agree with you, esp when
you are using code, where the userland venus(?) fetches all data for you
and feed it to the kernel when the luser needs it.

> Hence - my inquiry about a "clean" way of encapsulating and propagating
> credentials in the Unix "struct proc" model. There HAS to be a way of
> doing this that is clean, makes sense, and can make everyone happy.

Yes, tramsarc seem to steel two of the proc->groups to store its pag,
its is its the only thing I think you need. Then you can use diffrent
cred's for diffrent pid's as same user. If this could be solved in a more
beatiful and portable way, then :)

Let all diffrent protocol do their credential storing by themself,
but provide a way to get what cred's to use by the kernel ?

Love

sundance#~>groups
33537 41698 wheel authread