On Monday, March 21, 2005 07:11:30 PM -0500 Kyle Moffett <[EMAIL PROTECTED]> wrote:
I'm not sure whether every security mechanism will be able to deal with the server having to pass in a fixed blob at startup -- the current rxkad API involves the server passing in a callback, but it generally doesn't actually do much work (it looks up a key in a file, normally).
The security bit in that was just some random brainstorming. I haven't actually written any code for that bit yet. If you have any better ideas, I'd be glad to hear them. I'd prefer using keys via lookup in the Linux keyring system, although that won't work for other platforms, on Linux it's a cleaner API.
I really have to think about this some more. A lookup method will work for rxkad, but it may mean you can't make the fileserver start accepting a new key version just by adding it to the KeyFile, which I think works today.
I expect a lookup method can also be made to work for rxgk. I envision the context establishment being done in user mode (it's actually done via a series of unauthenticated RPC's to a special service). The result of context establishment is that the client gets a token it can use in the Rx security exchange; part of that token contains data encrypted in a key known only to the server. It seems like it would work quite well to give the kernel a copy of that key, and let it do the Rx security exchanges.
I'm just trying to wrap my head around whether using a keyring lookup is too restrictive.
A few other thoughts...
Rx has an additional layer of multiplexing below the UDP port, in which each request is for a particular service (named by an integer). Ideally, it would be possible to create separate listen sockets for separate services on the same port. To pick an extreme example, in a kaserver compiled with rxgk support, there may be as many as 7 services (the ubik vote and disk services, rx stats, rxgk context establishment, and three services provided by the kaserver), each serviced by completely separate code. Similarly, a client needs to be able to control what service it is making a call to. Presumably this means an extra field in the sockaddr.
How are you handling aborts? A server signals failure of an RPC by sending an abort packet containing a 32-bit error code. So, it needs to be possible for a server to send an abort with a specified error code. On the client side, attempts to read from an aborted call should return some sort of error, and the client should have a way of determining what the error code was.
An Rx call is essentially a short-lived stream-oriented data path, and both clients and servers need to be able to treat a call as a stream. So, it's best if in normal operation they can actually _use_ read and write, from a practical standpoint, rather than having to use sendmsg/recvmsg to do anything useful.
How are you handling call turnaround? Clients in particular need to be able to signal that it is time to turn around the connection.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
