3.2. RTI Security Plugins¶
This release of Security Plugins uses OpenSSL 1.0.2o. (Release 5.3.1 used OpenSSL 1.0.2n.)
Note: OpenSSL 1.0.2o fixes moderate severity vulnerabilities (RTI Issue ID PLATFORMS-1642), so it is recommended that you upgrade the version of OpenSSL that you are using to this one. For instructions on installing the latest version of OpenSSL, see the RTI Security Plugins Getting Started Guide.
The following issues affect backward compatibility in RTI Security Plugins.
188.8.131.52. Changed Authentication and Access Control property names¶
Starting with this release, you may use the property names that are in the DDS Security specification for configuring some attributes of the builtin Authentication and Access Control Plugins. See the section “Updated configuration property names” in the RTI Security Plugins Release Notes for a list of properties.
- The values of these properties require a prefix, which may be either
- If both the legacy and new properties are specified for a given attribute, the new property is applied, and the legacy property is ignored.
- The legacy
com.rti.servproperties are not equivalent to the new
dds.secproperties with respect to the inherit attribute of the
<property>tag in a QoS profile. For example, if profile “Base” specifies
<name>dds.sec.auth.identity_ca</name> <value>CaBase</value>and profile “Derived” (which has
<name>com.rti.serv.secure.authentication.ca_file</name> <value>CaDerived</value>, the CA will end up being “CaBase” because the two properties have different names, and the new property takes precedence over the old one.
To avoid confusion, it is recommended to update your property names to match
those in the DDS Security specification and to add the
file: prefix to
the corresponding property values. The
com.rti.serv.secure prefix should
be used only for RTI-specific property names. See the
Authentication chapter of the Security Plugins Getting Started Guide
for more information on these properties.
184.108.40.206. Changed default Persistence Service “dds.data_writer.history.key_material_key”¶
The undisclosed non-NULL default
dds.data_writer.history.key_material_key has changed. As a result,
Persistence Service databases protected with the old default key will not
be accessible by the new Persistence Service. Note that using the default
key is discouraged, and you should set
dds.data_writer.history.key_material_key to a value other than the default.
If you need to access a Persistence Service database encrypted with the old default key using a new version of Persistence Service, please contact RTI Support at email@example.com.
220.127.116.11. Changed Persistence Service encryption algorithm¶
The algorithm used to encrypt a Persistence Service database has changed to be more secure. As a result, databases protected with the old Persistence Service will not be accessible by the new Persistence Service.
18.104.22.168. Changed matching behavior of allowed partitions condition¶
The DDS Security specification
describes the matching behavior of the
<partitions> section within
<allow_rule> of a Permissions file.
In order for a DataWriter or DataReader to be matched with an
“allowed partitions” condition, the DDS entity’s partitions must be a
subset of the partitions in the condition. This release enforces this
To change this enforcement, you may set the security plugin property
access_control.use_530_partitions to TRUE. If TRUE, then a DataWriter or DataReader
will be matched with an “allowed partitions” condition as long as at least
one of the DDS entity’s partitions matches one of the partitions in the
condition; this is consistent with Connext DDS 5.3.0 behavior. If FALSE,
then the entity’s partitions must be a subset of the condition’s partitions;
this is consistent with the behavior of the DDS Security specification.
The default value is FALSE.
Here’s an example:
|DataWriter Partitions||Allowed Partitions Condition||use_530_partitions||allowed?|
|[A, B]||[B, C]||TRUE||yes, because B is in [B, C]|
|[A, B]||[B, C]||FALSE||no, because A is not in [B, C]|
22.214.171.124. Change to mutability of Publisher PartitionQosPolicy¶
The Publisher PartitionQosPolicy always used to be mutable. Now, it is immutable if the Publisher contains any DataWriter that meets both of the following two criteria:
- The TopicSecurityAttributes for that DataWriter have
is_read_protected(which corresponds to
<enable_read_access_control>in the Governance Document) set to TRUE.
- The DataWriter has the DurabilityQosPolicy
kindset to something other than VOLATILE.
126.96.36.199. New protection for Builtin Logging Topic¶
This release changes the Governance XML setting
from NONE to SIGN for the Builtin Logging Topic. This change was made to be
compliant with the
DDS Security specification.
It breaks configuration compatibility between this and previous releases
when using a DataReader to subscribe to the Builtin Logging Topic. The DataReader must
now be configured to use
metadata_protection_kind = SIGN.
To change this behavior, you may set the security plugin property
access_control.use_530_logging_protection to TRUE. If TRUE, then the
metadata_protection_kind will be NONE for the Builtin Logging Topic,
which is consistent with Connext DDS 5.3.0 behavior. The default value is FALSE.
3.2.2. Wire Compatibility¶
188.8.131.52. Participants and endpoints using inconsistent security configuration do not communicate¶
This release adds support for the new DDS Security 1.1 participant/endpoint security matching, which allows for early detection of incompatible security configurations. To support this feature, participants will announce new parameters as part of the participant/endpoint discovery. See What’s New in 6.0.0 in the Security Plugins Release Notes.
The propagation of these parameters is enabled by default. Since their propagation introduces additional restrictions for participant and endpoint matching, participants and endpoints may stop communicating after upgrading to 6.0.0 if they are using a configuration considered incompatible according to the DDS Security specification.
To support scenarios relying on inconsistent security configurations, the following new properties have been introduced (not used by default):
|Property Name ||Property Value Description|
If set to FALSE, the endpoint’s
If set to FALSE, the participant’s
184.108.40.206. Changes in DDS types and definitions¶
The following changes were made to match the DDS Security specification:
- Added new
- Moved the following from
- Changed the
DDS_TrustException) definition and removed the
NOT_ALLOWED_BY_SEC(value 13) to
220.127.116.11. Changes in APIs¶
- Added the following APIs to the Access Control plugin interface to match the DDS Security specification:
- Removed the
get_endpoint_sec_attributesAPI from the Access Control plugin interface.
validate_remote_identityto include AuthRequestMessageToken parameters.
process_auth_requestAPIs from the Authentication plugin interface.
check_remote_datareaderto include the
check_local_datareader_matchto include publication/subscription data parameters and to remove the tags parameter.
- Added “const” to non-primitive input parameters of APIs of Authentication, Access Control, and Cryptography plugins.
18.104.22.168. get_datawriter_sec_attributes and get_datareader_sec_attributes must support receiving builtin topic names¶
did not expect to receive builtin topic names, only user topic names.
In this release, to be compliant with DDS Security 1.1,
the core libraries can call
get_datareader_sec_attributes to retrieve the endpoint security attributes
for builtin (secure and non-secure) DataWriters and DataReaders. As such, custom security
plugins need to be updated to support receiving the following topic name
- DDS discovery topics:
- DDS liveliness topic:
- DDS Security secure discovery topics:
- DDS Security secure liveliness topic:
- Other DDS Security topics:
- RTI non-secure topics:
- RTI secure topics:
|||These new properties do not need to be prefixed with ‘com.rti.serv.secure.’|