.. include:: ../vars.rst

.. _chapter-differences-wrt-spec:

****************************************************************************************
What's Different Between the |RTI_SP_PRODUCT_HEADING| and the OMG Security Specification
****************************************************************************************

This chapter describes differences between |RTI_SP_PRODUCT| |CONNEXT_CURRENT_VERSION| and
the |SEC_SPEC_11|.
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_PRODUCT| that conflict with the |SEC_SPEC|).

Differences Affecting Builtin Plugins to be Addressed by Next DDS Security Specification
========================================================================================

Access Control
--------------

Mutability of Publisher PartitionQosPolicy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, :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`.

|SEC_SPEC_12| changes 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 |RTI_SP_PRODUCT| 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)`.)


Configurability of ProtectionKind used by TypeLookup Service Channel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The |SEC_SPEC_12|, :emphasis:`Table 21 - EndpointSecurityConfig for all Builtin Security Endpoints`, defines the :property:`is_submessage_protected` value of the TypeLookupServiceRequestSecure and TypeLookupServiceReplySecure endpoints to be :value:`TRUE`, and the protection kind is underspecified (defaulting to `ENCRYPT`).
This does not provide the user with any way to protect against insider attacks.
|RTI_SP_PRODUCT| includes an additional ProtectionKind, :xmltag:`type_lookup_protection_kind` that can be set to :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION` to prevent against these kinds of attacks.

A future version of the specification will add the
:xmltag:`type_lookup_protection_kind` (already provided by RTI) to remedy this.

Differences Affecting Builtin Plugins
=====================================

General
-------

Support for Infrastructure Services
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `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 |RTI_SP_PRODUCT| functions include this additional parameter, the |RTI_SP_PRODUCT| 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 <default> rule in the Permissions Document
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `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_BUILTIN|
do not check the default rule's placement.


Differences Affecting Custom Plugins
====================================

Authentication
--------------

Revocation
^^^^^^^^^^

The |SEC_SPEC_11|, `Section 8.3.2.12 AuthenticationListener`, describes the
mechanism for revoking identities. The |SP_BUILTIN| invoke ``on_status_changed()``
when a certificate revocation list (CRL) has changed. The |RTI_SP_PRODUCT|
invoke a different function, ``validate_status()``, for determining whether a
specific identity has been revoked.

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
|SEC_SPEC_11|, `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 |SEC_SPEC_11|, `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 |SEC_SPEC_11|, `Section 8.4.2.9.12 Operation: check_remote_topic`,
describes the ``check_remote_topic()`` operation. The |RTI_SP_PRODUCT| do not invoke this operation.


check_local_datawriter_register_instance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `Section 8.4.2.9.7 Operation: check_local_datawriter_register_instance`, describes the ``check_local_datawriter_register_instance()`` operation. The |RTI_SP_PRODUCT| do not implement this operation.


check_local_datawriter_dispose_instance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `Section 8.4.2.9.8 Operation: check_local_datawriter_dispose_instance`, describes the ``check_local_datawriter_dispose_instance()`` operation. The |RTI_SP_PRODUCT| do not implement this operation.


check_remote_datawriter_register_instance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `Section 8.4.2.9.15 Operation: check_remote_datawriter_register_instance`, describes the ``check_remote_datawriter_register_instance()`` operation. The |RTI_SP_PRODUCT| do not implement this operation.


check_remote_datawriter_dispose_instance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `Section 8.4.2.9.16 Operation: check_remote_datawriter_dispose_instance`, describes the ``check_remote_datawriter_dispose_instance()`` operation. The |RTI_SP_PRODUCT| 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 |SEC_SPEC_11|, `Section 8.4.2.10 AccessControlListener interface`, describes the mechanism for revoking permissions. The |RTI_SP_PRODUCT| do not implement this mechanism.


PermissionsToken
^^^^^^^^^^^^^^^^

The |SEC_SPEC_11|, `Table 10 Additional parameter IDs in ParticipantBuiltinTopicData`, mentions ``PermissionsToken`` as a new parameter in ``ParticipantBuiltinTopicData``. The |RTI_SP_PRODUCT| 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 |SEC_SPEC_11|, `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.
