.. 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_external_security_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_external_security_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_external_security_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 Document's :xmltag:`allow_rule` and :xmltag:`deny_rule` is ignored. Access Control -------------- Placement of the rule in the Permissions Document ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_external_security_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_external_security_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`). Discovery Failure If Exchanging Fewer Than Two Handshake Messages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If two |DPs| use a custom authentication plugin in which at least one |DP| does not send any handshake messages, then the endpoints of the |DPs| may fail to discover each other. Such a plugin is possible according to the :link_external_security_spec:`DDS Security specification <1.1>`, `Figure 9 - Authentication plugin interaction state machine` (if ``validate_remote_identity()`` returns ``VALIDATION_OK`` in at least one |DP|), and the specification gives no indication that such a plugin should result in discovery failure. The :link_external_security_spec:`DDS Security specification <1.1>`, `Table 55 - Description of built-in authentication protocol` indicates that the builtin authentication plugin uses three total handshake messages: two from one |DP| and one from the other |DP|. The |SP| builtin authentication plugin follows this approach, so the discovery failure will not happen unless you are using a custom authentication plugin. Access Control -------------- check_remote_topic ^^^^^^^^^^^^^^^^^^ The :link_external_security_spec:`DDS Security specification <1.1>`, `Section 8.4.2.9.12 Operation: check_remote_topic`, describes the ``check_remote_topic()`` operation. The |SP| do not invoke this operation. check_local_datawriter_register_instance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_external_security_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_external_security_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_external_security_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_external_security_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_external_security_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_external_security_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. Cryptography ------------ inline_qos for encode/decode_serialized_payload ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The :link_external_security_spec:`DDS Security specification <1.1>`, `Table 38 - CryptoTransform interface`, indicates that the ``encode_serialized_payload()`` operation outputs an ``extra_inline_qos`` parameter and that the ``decode_serialized_payload()`` operation inputs an ``inline_qos``. |CONNEXT| does not support either of these parameters.