Policy Dissemination

This page puts forth deferent modalities of policy dissemination for access control. Policies are used to help define the resources and actions that identifies are authorized to engage. For SROS, identifies are ROS nodes and policy permissions encompass the ROS API:

• (resource)
  • [actions]
• topics
  • publish
  • subscribe
• parameters
  • read
  • write
• services
  • advertise
  • call
• ROS API
  • master calls
  • slave calls

To disseminate this information on what a node is allowed to preform, there are several school of thought on mater. Here we'll explore each and expand upon their strengths and weaknesses.

Certificate Embedding

Certificates, such as the X.509 standard can be used as vessels for policy constraints. Specifically, X.509 possess standardized extensions used to encode policy meta data, such that it can be singed and verified via PKI and CAs to avoid tampering of the imposed restrictions by end parties. SROS currently uses X.509 certificate and for TLS handshaking when establishing a secure network socket connection between nodes. These certificates is also used as a payload for conveying policy information to prove to the peer node it is authorized to access the requested resource with the requested action. Let us flesh out some pros and cons of this approach:

Pros

• Certificates Verification
  • Policy restrictions ascertained from the certificate can be checked for integrity, validity, authority, and revocation, preventing unauthorized escalation of permissions, or issuing from a false sources of trust.
• Computation Reuse
  • The same certificate is already checked during the TLS handshake, sparing the application layer the delicate and time consuming computation of challenging the ownership of an additional certificate encapsulating policies.
• Policy is immutable
  • Once certificates are deployed, the interpretation of policy restrictions are autonomous and self explanatory. Changing policies post deployment would require redistribution of new issued certificates, but without access to private keys for a trusted CA, alteration is not possible.

Cons

• Policy data is public
  • Policy restrictions are embedded into the public certificate, thus observable from anyone who observes the certificate exchanged. This may be undesirable if topic, parameter, or service call names themselves are sensitive information, supporting organizational analysis. Solving this would require obfuscation of such meta-data itself through naming schema or common cyphers.
• Policy is immutable
  • Once certificates are deployed, changing policies dynamically would require redistribution of newly issued certificates. Without invalidating old certificates and making so know to all parties involved, intended deescalation or revocation of previous policies would not be guaranteed. Solving this would require additional machinery to service revocations inquiries (such as CRLs or better yet OCSP), and callback mechanisms to notify nodes of new issued certificates use in circulation.

Online Arbiter

An arbiter, or centralized authority, could also be used to authorize requested exchanges. Specifically, a process that is made aware of the global policy definition could be contacted by nodes in the process of negotiating access to deliberate judgment on whether the requested resource/action is permissible by the inquiring identity. This is similar to the existing DNS like behavior of the master node in ROS1, but instead of resolving namespaces, the arbiter would resolve access control restrictions.

Pros

• Dynamic Policies
  • With a central agent knowable of the global policy, updating policy definitions online is readily doable, and no redistribution of new public certificates would be required. Such is useful when you are unable to formulate a flexible policy procedure before runtime.

Cons

• Single Point of Failure
  • As the role of the arbiter necessitates it's consent operation alongside the rest of the ROS stack, it would serve as a primary target to compromise the entire existing ROS graph. In this winner take all scenario, those who exploit arbiter or find venerabilities in connecting to it control all access in the graph.
• Connection Overhead
  • Because policy restrictions are not exchanged between nodes, nodes must defer to the arbiter. This requires the both the connecting and accepting peers in a P2P connection to open an second connection to the arbiter to make there receptive inquiries about the other. This adds latency in each step of the ROS API, as additional networked round trips and response time must be accounted for.