Where should port rights go?

[Farid Hajji]

Many ways to implement port rights come to mind. Here are some ideas:

(*: remarks, -: disadvantages, +: advantages)

0. in the ukernel itself:

    * Mach's way.
    - Not available on L4
    + ukernel is trusted entity
    + easily/quickly available at each IPC call

1. in the auth server:

    * auth stores a table of port rights and can be queried by
      concerned parties to verify the rights.
    * auth is considered as a trusted entity.
    - auth would be come a bottleneck of ipc comms.
    - mixing unix-like [ug]id(s) with lower-level port rights.
    + a single authority that can be easily implemented.
    + an obvious place where to store the port rights.

2. in a l4-mach server:

    * l4-mach server would conserve the state of a mach kernel that cannot
      be kept by L4. It would be contacted by libmachemu (or whatever
      we call it) when necessary. port rights could be saved in l4-mach.
    * l4-mach is considered a trusted entity.
    - l4-mach can become a IPC bottleneck for multiple queries.
    - l4-mach is already busy enough servicing other libmachemu-calls.
    + no mixing of unix-like OS personality and low-level port rights.
    + minimal changes to the Hurd sources (e.g. libports) required,
      therefore fast porting.

3. in a dedicated port-rights server:

    * a separate port-rights server could be used to store and query
      port rights.
    * port-rights server considered trusted entity.
    - port-rights server would become a IPC bottleneck for multiple queries.
    + clean separation of abstractions
    + easily implementable

4. in each ipc message, with trusted party:

    * each ipc message carries a non-forgeable tag describing a port right
      that was originally obtained from a trusted entity.
    * the trusted entity hands out signed port-rights when required.
      These port-rights are then passed in every RPC message and checked
      by the sending/receiving threads.
    * trusted entity has well-known public key that is used by every
      other party in verifying the signed port-right.
    * port-rights are signed with additional information (like intended
      server-id, receiver-id, timestamp).
    - trusted entity still IPC bottleneck, but less strain on it.
    - overhead of checking digital signature of the port right.
    - digital signatures are often too big for short messages.
    + port-rights are only requested when a new IPC path is established.
      Afterwards, they are just checked by the communicating parties,
      not asking trusted entity anymore.
    + port-rights are timestamped and could expire after a variable delay.
    + port-rights are stamped with source/destination, so no other party
      can steal the ticket
    + port-rights are non-forgeable, since they are privately signed from 
      the trusted entity whose public key is well-known.

5. in initial ipc message, subsequent messages using sequence numbers,
   with trusted party.

    * like 4, but the signed ticked is only transmitted while setting
      up a communication (like a TCP connect(), so to say...). The rest
      of the communication uses simple sequence numbers that are small
      enough to fit in a short message.
    * to avoid eavesdropping and manipulation, each party could randomize
      the sequence numbers. That should be only necesary when connecting
      to remote nodes (?).
    - trusted entity still IPc bottleneck, but less strain on it.
    - overhead of checking digital signatures in simple one-way IPC comm.
    + overhead of checking digital signatures only on communication setup.
    + signed port-right only transmitted once in a long-message, then
      sequence numbers used for short-messages.
    - always signed port-rights transmitted in long-messages in short
      communications.
    + port-rights are timestamped, stamped with source/destination and
      non-forgeable for the same reasons as in 4.

6. in ipc messages, no trusted port-rights server, trusted keyserver:

    * every party generates a private/public key pair and advertises
      its public key to the trusted keyserver (it could as well be
      the proc server, or a dedicated keyserver).
    * [do we need port rights, if each server is uniquely defined by
       its public key? Hmmm...]
    * each message contains a ticket that is signed by the sender and
      verifyed by the recipient (against the [cached list of] public-key
      database).
    * keyserver is trusted entity.
    - tickets are bigger than a short message.
    - overhead of making/checking signatures on both sides of a comm.
    + keyserver contents can be cached by concerned parties.
    + less hits on the keyserver than on the port-rights server.
    + port-rights are timestamped, stamped with source/destination and
      non-forgeable (because of trusted public keys of originators).

7. in initial ipc messages, no trusted port-rights server, trusted keyserver:

    * like 6, but signed ticked only used for initial communications setup.
    * same as in 5.

8. no trusted party?

9. <other ideas go here...>

Please feel free to ask questions if you don't understand what's
described above.

Thanks,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.