14. What’s Different Between the Security Plugins and the OMG Security Specification

This chapter describes differences between Security Plugins 7.3.0 and the OMG DDS Security 1.1 specification. This section does not include additional features, but differences that can be considered as known issues (either missing functionality or behaviors from the Security Plugins that conflict with the OMG DDS Security specification).

14.1. Differences Affecting Builtin Plugins to be Addressed by Next DDS Security Specification

14.1.1. Access Control

14.1.1.1. Mutability of Publisher PartitionQosPolicy

The OMG DDS Security 1.1 specification, Section 7.3.5 Immutability of Publisher Partition Qos in combination with non-volatile Durability kind, defines the kind of DataWriters that a Publisher must contain in order for its PartitionQosPolicy to be immutable. These DataWriters meet the following two criteria:

The DataWriter either encrypts the SerializedPayload submessage element or encrypts the Data or DataFrag submessage elements.
The DataWriter has the DurabilityQosPolicy kind set to something other than VOLATILE.

OMG DDS Security 1.2 specification (pending publication) will change the first criterion to be the following:

The TopicSecurityAttributes for that DataWriter have is_read_protected set to TRUE.

The second criterion still applies. The Security Plugins use this new criterion to determine PartitionQosPolicy immutability. (is_read_protected corresponds to enable_read_access_control in the Governance Document, see enable_read_access_control (topic_rule).)

14.2. Differences Affecting Builtin Plugins

14.2.1. General

14.2.1.1. Support for Infrastructure Services

The OMG DDS Security 1.1 specification, 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 Security Plugins functions include this additional parameter, the Security Plugins do not implement this mechanism, and the parameter is currently not used or populated. As such, the relay tag under the Permissions Document’s allow_rule and deny_rule is ignored.

14.2.2. Access Control

14.2.2.1. Placement of the <default> rule in the Permissions Document

The OMG DDS Security 1.1 specification, 9.4.1.3.2.3 Rules Section, specifies that the default rule, if present, must appear after all allow and deny rules. The Builtin Security Plugins do not check the default rule’s placement.

14.3. Differences Affecting Custom Plugins

14.3.1. Authentication

14.3.1.1. Revocation

The OMG DDS Security 1.1 specification, Section 8.3.2.12 AuthenticationListener, describes the mechanism for revoking identities. The Builtin Security Plugins invoke on_status_changed() when a certificate revocation list (CRL) has changed. The Security Plugins invoke a different function, validate_identity_status(), for determining whether a specific identity has been revoked.

14.3.1.2. Discovery Failure If Exchanging Fewer Than Two Handshake Messages

If two DomainParticipants use a custom authentication plugin in which at least one DomainParticipant does not send any handshake messages, then the endpoints of the DomainParticipants may fail to discover each other. Such a plugin is possible according to the OMG DDS Security 1.1 specification, Figure 9 - Authentication plugin interaction state machine (if validate_remote_identity() returns VALIDATION_OK in at least one DomainParticipant), and the specification gives no indication that such a plugin should result in discovery failure.

The OMG DDS Security 1.1 specification, Table 55 - Description of built-in authentication protocol indicates that the builtin authentication plugin uses three total handshake messages: two from one DomainParticipant and one from the other DomainParticipant. The Builtin Security Plugins authentication plugin follows this approach, so the discovery failure will not happen unless you are using a custom authentication plugin.

14.3.2. Access Control

14.3.2.1. check_remote_topic

The OMG DDS Security 1.1 specification, Section 8.4.2.9.12 Operation: check_remote_topic, describes the check_remote_topic() operation. The Security Plugins do not invoke this operation.

14.3.2.2. check_local_datawriter_register_instance

The OMG DDS Security 1.1 specification, Section 8.4.2.9.7 Operation: check_local_datawriter_register_instance, describes the check_local_datawriter_register_instance() operation. The Security Plugins do not implement this operation.

14.3.2.3. check_local_datawriter_dispose_instance

The OMG DDS Security 1.1 specification, Section 8.4.2.9.8 Operation: check_local_datawriter_dispose_instance, describes the check_local_datawriter_dispose_instance() operation. The Security Plugins do not implement this operation.

14.3.2.4. check_remote_datawriter_register_instance

The OMG DDS Security 1.1 specification, Section 8.4.2.9.15 Operation: check_remote_datawriter_register_instance, describes the check_remote_datawriter_register_instance() operation. The Security Plugins do not implement this operation.

14.3.2.5. check_remote_datawriter_dispose_instance

The OMG DDS Security 1.1 specification, Section 8.4.2.9.16 Operation: check_remote_datawriter_dispose_instance, describes the check_remote_datawriter_dispose_instance() operation. The Security Plugins do not implement this mechanism.

14.3.2.6. 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.

14.3.2.7. Revocation

The OMG DDS Security 1.1 specification, Section 8.4.2.10 AccessControlListener interface, describes the mechanism for revoking permissions. The Security Plugins do not implement this mechanism.

14.3.2.8. PermissionsToken

The OMG DDS Security 1.1 specification, Table 10 Additional parameter IDs in ParticipantBuiltinTopicData, mentions PermissionsToken as a new parameter in ParticipantBuiltinTopicData. The Security Plugins send this parameter, but when receiving this parameter, it is not used in any Access Control functionality. The builtin Access Control Plugin is specified to use PermissionsToken to validate the Access Control plugin name and version of previously authenticated remote participants.

14.3.3. Cryptography

14.3.3.1. inline_qos for encode/decode_serialized_payload

The OMG DDS Security 1.1 specification, 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.