.. include:: ../vars.rst .. _chapter-differences-wrt-spec: ************************************************************************************ What's Different Between the RTI Security Plugins and the OMG Security Specification ************************************************************************************ This chapter describes differences between |RTI_SP| |CONNEXT_currentVersion| and the :link_sec_spec:`OMG DDS Security specification (version 1.1) <1.1>`. This section does not include additional features, but differences that can be considered as known issues (either missing functionality or behaviors from the |RTI_SP| that conflict the DDS Security specification). Differences Affecting Builtin Plugins to be Addressed by Next DDS Security Specification ======================================================================================== Access Control -------------- Mutability of Publisher PartitionQosPolicy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, :emphasis:`Section 7.3.5 Immutability of Publisher Partition Qos in combination with non-volatile Durability kind`, defines the kind of |DWs| that a |PUB| must contain in order for its PartitionQosPolicy to be immutable. These |DWs| meet the following two criteria: #. The |DW| either encrypts the SerializedPayload submessage element or encrypts the Data or DataFrag submessage elements. #. The |DW| has the DurabilityQosPolicy kind set to something other than :xmlval:`VOLATILE`. The next version of the specification will change the first criterion to be the following: #. The TopicSecurityAttributes for that |DW| have :property:`is_read_protected` set to :value:`TRUE`. The second criterion still applies. The |SP| use this new criterion to determine PartitionQosPolicy immutability. (:property:`is_read_protected` corresponds to :xmltag:`enable_read_access_control` in the Governance Document, see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`.) Differences Affecting Builtin Plugins ===================================== General ------- Support for Infrastructure Services ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 7.1.1.4 Unauthorized Access to Data by Infrastructure Services`, describes the mechanism for preventing unauthorized access to data by infrastructure services. To support this capability, certain functions have an output parameter called ``relay_only``. While |SP| functions include this additional parameter, the |SP| do not implement this mechanism, and the parameter is currently not used or populated. As such, the :xmltag:`relay` tag under the Permissions File's :xmltag:`allow_rule` and :xmltag:`deny_rule` is ignored. Access Control -------------- Placement of the rule in the Permissions File ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `9.4.1.3.2.3 Rules Section`, specifies that the default rule, if present, must appear after all allow and deny rules. The |SP| do not check the default rule's placement. Differences Affecting Custom Plugins ==================================== Authentication -------------- Revocation ^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.3.2.12 AuthenticationListener`, describes the mechanism for revoking identities. The |SP| do not implement this mechanism. This release supports looking up a certificate revocation list (CRL) during |DP| creation and discovery (see :ref:`p2_core/elements_dds_secure_system:Certificate Revocation`). Access Control -------------- check_local_datawriter_register_instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.4.2.9.7 Operation: check_local_datawriter_register_instance`, describes the ``check_local_datawriter_register_instance()`` operation. The |SP| do not implement this operation. check_local_datawriter_dispose_instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.4.2.9.8 Operation: check_local_datawriter_dispose_instance`, describes the ``check_local_datawriter_dispose_instance()`` operation. The |SP| do not implement this operation. check_remote_datawriter_register_instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.4.2.9.15 Operation: check_remote_datawriter_register_instance`, describes the ``check_remote_datawriter_register_instance()`` operation. The |SP| do not implement this operation. check_remote_datawriter_dispose_instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.4.2.9.16 Operation: check_remote_datawriter_dispose_instance`, describes the ``check_remote_datawriter_dispose_instance()`` operation. The |SP| do not implement this mechanism. check_local_datawriter_match / check_local_datareader_match ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When calling ``check_local_datawriter_match()`` / ``check_local_datareader_match()``, the ``subscription_data`` and ``publication_data`` parameters are not set. Revocation ^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.4.2.10 AccessControlListener interface`, describes the mechanism for revoking permissions. The |SP| do not implement this mechanism. PermissionsToken ^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Table 10 Additional parameter IDs in ParticipantBuiltinTopicData`, mentions ``PermissionsToken`` as a new parameter in ``ParticipantBuiltinTopicData``. The |SP| send this parameter, but when receiving this parameter, it is not used in any Access Control functionality. The builtin |AccessControlPlugin| is specified to use ``PermissionsToken`` to validate the Access Control plugin name and version of previously authenticated remote participants. check_remote_topic ^^^^^^^^^^^^^^^^^^ The :link_sec_spec:`DDS Security specification <1.1>`, `Section 8.4.2.9.12 Operation: check_remote_topic`, describes the ``check_remote_topic()`` operation, which receives a ``TopicBuiltinTopicData`` as an input. Instead of invoking this operation when the remote |DP| creates a certain |TOPIC|, |CONNEXT| invokes this operation when discovering the first |DW| or |DR| belonging to that |TOPIC|-|DP| combination. This distinction matters if the implementation of ``check_remote_topic()`` considers any of the QosPolicies within the ``TopicBuiltinTopicData`` structure. (The builtin plugins do not consider these QosPolicies.) For example, if a |DP|, |P1|, creates two |DRs| of the same topic, another |DP|, |P2|, will call ``check_remote_topic()`` only when it discovers the first |DR|. If the second |DR|'s DeadLineQosPolicy matches that of |P1|'s TopicQos and the first |DR|'s DeadlineQosPolicy does not match, then ``check_remote_topic()`` will receive the wrong DeadlineQosPolicy as part of the input ``TopicBuiltinTopicData``. This problem will only occur if ``check_remote_topic()`` considers the DeadlineQosPolicy when deciding whether to return ``TRUE`` or ``FALSE``.