4. What’s New in 7.2.0

This section describes what’s new, compared to the RTI Security Plugins 7.1.0.

This section includes descriptions of products, features, and platforms that are deprecated or removed starting in release 7.2.0.

Deprecated means that the item is still supported in this release, but will be removed in a future release. Removed means that the item is discontinued or no longer supported. By specifying that an item is deprecated in this release, RTI is hereby providing customer notice that RTI reserves the right after one year from the date of this release and, with or without further notice, to immediately terminate maintenance (including without limitation, providing updates and upgrades) for the item, and no longer support the item, in a future release.

This section serves as notice under the Real-Time Innovations, Inc. Maintenance Policy #4220 and/or any other agreements by and between RTI and customer regarding maintenance and support of RTI’s software.

4.2. Changes Related to Access Control

4.2.1. Improved endpoint discovery time by removing redundant calling of check_remote_topic

The DDS Security specification describes the Access Control plugin operation check_remote_topic(). This function was implemented and invoked during endpoint discovery starting from Security Plugins 6.0.0. However, due to the absence of TopicBuiltinTopicData propagation, this invocation did not serve an effective security purpose and was redundant due to the operations check_remote_datawriter() and check_remote_datareader(). Moreover, the presence of check_remote_topic() made custom plugins code more error prone and potentially led to vulnerabilities when incorrectly used as a partial or complete replacement of check_remote_datawriter() or check_remote_datareader().

For these reasons, the Security Plugins no longer call check_remote_topic(). See the Migration Guide on the RTI Community Portal for migration issues related to this removal.

4.2.2. Security Plugins for wolfSSL now support key usage extensions

The Security Plugins for wolfSSL now support enforcing the presence of the keyUsage X.509 v3 extension. In previous releases, this feature was supported only in the Security Plugins for OpenSSL.

You can now configure the Security Plugins for wolfSSL to only accept certificates including X.509 v3 key usage extensions. For more information, see the authentication.x509v3_extension_enforcement.key_usage property in Table 4.2 RTI Security Plugins Properties for Configuring Authentication of the Security Plugins User’s Manual.

4.2.3. Secured communications between RTI Monitoring Library 2.0 and RTI Observability Collector Service

The telemetry data published by RTI Monitoring Library 2.0 (previously known as RTI Observability Library) might contain sensitive information about your RTI Connext applications (for example, logging messages). Sensitive information must be protected from unauthorized access.

Starting with Connext 7.2.0, RTI Security Plugins can be enabled for both RTI Monitoring Library 2.0 and RTI Observability Collector Service. DDS traffic containing metrics and logs can be encrypted or signed, and subscription permissions to telemetry data can be configured.

Security Plugins can be enabled for Monitoring Library 2.0 through XML using the monitoring.distribution_settings.dedicated_participant.participant_qos_profile_name tag with a QoS profile that asserts the security artifacts. The Observability Collector Service Docker image also provides built-in configurations for enabling the Security Plugins either if it is deployed using RTI’s prepackaged Docker Compose or as a separate Docker deployment.

New tags in the Governance and Permissions documents provide an easy and flexible way of configuring security for the Observability Framework topics and entities:

The monitoring_metrics_protection_kind and monitoring_logging_protection_kind tags of the Governance document determine the level of protection applied to metrics and logs, respectively:

<dds>
    <domain_access_rules>
        <domain_rule>
            ...
            <monitoring_metrics_protection_kind>SIGN</monitoring_metrics_protection_kind>
            <monitoring_logging_protection_kind>ENCRYPT</monitoring_logging_protection_kind>
            ...
        </domain_rule>
    </domain_access_rules>
</dds>

The subscribe_monitoring tag of the Permissions document determines the telemetry data Observability Collector Service is allowed to subscribe (metrics and logs, just metrics, or nothing). Publishing telemetry data is always allowed:

<dds>
    <permissions>
        <grant name="Participant_Monitoring">
            <subject_name>...</subject_name>
            <validity>...</validity>
            <allow_rule>
                ...
                <subscribe_monitoring>ALL</subscribe_monitoring>
            </allow_rule>
            <default>DENY</default>
        </grant>
    </permissions>
</dds>

For additional information, see Security in the Observability Framework User’s Manual.

4.5. Changes Related to Discovery and Authentication

4.5.1. Enabled configuration of protection kind for the builtin service request channel

Previously, the protection kind of the builtin service request channel was inferred from the discovery protection kind configured in the governance file. A new domain-level rule has been added to the governance file that allows the protection kind of the service request channel to be explicitly configured: service_request_protection_kind. If service_request_protection_kind is not set in the governance file, the protection kind is inherited from discovery_protection_kind. When the protection kind is inherited from discovery, the service_request_protection_kind is not propagated during discovery.

4.5.2. Support retrieving subject name of a remote DomainParticipant that is not authenticated yet

This release introduces support for retrieving the subject name of a remote DomainParticipant that is not authenticated yet. This feature allows you to make dynamic permissions decisions based on the subject name. You can do so using the discovered_participant_subject_name, ignore_participant, and banish_ignored_participants APIs in the on_data_available callback of the DDS_ParticipantBuiltinTopicData’s DataReader.

This feature is possible because DomainParticipants can now propagate their Identity Certificate’s Subject Name during discovery. They will only propagate their Identity Certificate’s Subject Name if the value of the authentication.enable_discovery_subject_name_propagation property is TRUE. The advantage of setting the property to TRUE is that it allows a remote DomainParticipant to get the Subject Name of the Identity Certificate before completing authentication.

If the property value is FALSE (default value), the local DomainParticipant won’t propagate the Subject Name of its Identity Certificate during discovery. This configuration reduces discovery overhead. The disadvantage is that if a remote DomainParticipant calls discovered_participant_subject_name before authenticating the local DomainParticipant, this function will return DDS_RETCODE_NO_DATA.

4.5.3. SPDP2 participant announcements now subject to sample signature verification

TrustedState is a Security Plugins mechanism that ensures that the contents of a participant discovery message are legitimate. TrustedState has previously only been supported with Simple Particpant Discovery (SPDP) participants. Starting with this release, TrustedState is supported in Simple Participant Discovery 2.0 (SPDP2) participants, too.

See Simple Participant Discovery 2.0, in the RTI Connext Core Libraries User’s Manual for more information about SPDP2.

4.5.4. Re-validation of remote participant data after authorization

A DomainParticipant will now re-validate a change in the remote participant data even after initial authorization completes. If a field in the remote participant data changes to a value that violates the permissions document, the remote participant will be removed. This enhancement applies to both SPDP and SPDP2 participants.

See Simple Participant Discovery 2.0, in the RTI Connext Core Libraries User’s Manual for more information about SPDP2.

4.5.5. Unauthorized remote participants now removed instead of ignored, allowing for re-authorization

Previously, if a remote DomainParticipant failed authorization it would be ignored, meaning that authorization would not be attempted again, even if the remote participant changed its properties. Because mutable fields can now be re-validated after authorization, authorization failures no longer ignore a remote participant, but simply remove it. If a participant fails authorization because it has an unallowed partition, but it then changes to an allowed partition, the Security Plugins now re-perform authentication and authorization, and ultimately authorize the participant. This change applies to both SPDP and SPDP2 participants.

See Simple Participant Discovery 2.0, in the RTI Connext Core Libraries User’s Manual for more information about SPDP2.

4.6. Changes Related to Dynamic Participant Renewal, Revocation, and Expiration

4.6.1. Dynamically control access to your Connext Secure system using a whitelist of trusted subject names

A new DomainParticipant PropertyQos property, dds.participant.trust_plugins.subject_name_whitelist, enables you to dynamically control system access using a whitelist. dds.participant.trust_plugins.subject_name_whitelist configures a whitelist of subject names for authenticated DomainParticipants. If set (even if set to an empty string), an authenticated DomainParticipant is allowed into the system only if its subject name matches one in the whitelist. Any authenticated DomainParticipant whose subject name does not match the whitelist will be ignored automatically.

This property does not affect allowed, non-authenticated participants; the whitelist is enforced only on authenticated DomainParticipants. If the list is modified after a DomainParticipant is enabled, any DomainParticipant that was previously ignored will be unignored. This creates an opportunity to successfully authenticate if the DomainParticipant subject name is in the updated whitelist; if not, the DomainParticipant will be ignored as usual.

4.6.2. Added configuration option for certificate expiration notice frequency

In 7.1.0, according to Dynamic Certificate Expiration of the Local DomainParticipant, if you implemented the on_invalid_local_identity_status_advance_notice callback function and the certificate was going to expire within the advance notice duration, then the Security Plugins would notify you every second that your certificate was about to expire. The frequency of this notification is now configurable using the property dds.participant.trust_plugins.certificate_expiration_advance_notice_reminder_period.sec. For more information, see 4. Authentication in the RTI Security Plugins User’s Manual 7.2.0 documentation.

4.6.3. Increased robustness against DomainParticipants leaving the system before their certificates become expired or revoked

As described in Dynamic Certificate Expiration of Remote DomainParticipants, in the RTI Security Plugins User’s Manual 7.1.0, the Security Plugins will automatically create a new Key Revision in order to render a DomainParticipant’s Key Material outdated when the DomainParticipant’s certificate expires. In previous versions, this mechanism worked when the expiration happened before the DomainParticipant leaves the system, but it did not work when the expiration happened after the DomainParticipant left the system. So if Participant A lost liveliness of Participant B, and then Participant B’s certificate expired, then Participant B would still be able to decrypt messages that Participant A was sending to Participant C if Participant B was able to intercept those messages.

In this release, the Security Plugins close this loophole by automatically creating a new Key Revision whenever a previously-alive DomainParticipant’s certificate becomes expired or revoked. The number of previously-alive DomainParticipants to keep track of is configurable using the new property dds.participant.trust_plugins.max_removed_participants_per_key_revision. For more information, see Properties for Configuring Cryptography Affecting Any Cryptography Plugin, in the RTI Security Plugins User’s Manual.

4.6.4. Improved debuggability, usability, and forward compatibility of Key Revisions

As described in Crypto Header, in the 7.0.0 RTI Security Plugins User’s Manual, the interpretation of four of the bytes in the Crypto Header depended on whether or not Key Revisions were enabled (using the dds.participant.trust_plugins.key_revision_max_history_depth property). This ambiguous behavior hindered debuggability; for example, it prevented Wireshark from accurately dissecting the Crypto Header.

This release changes that behavior. Now, the interpretation of those four bytes is always the same, regardless of the value of the dds.participant.trust_plugins.key_revision_max_history_depth property. This change impacts backward compatibility with 7.1.0, as described in the Migration Guide, but it improves forward compatibility with future releases. In addition, this behavior improves the usability of RTPS PSK Protection because the Security Plugins can now easily distinguish between a mismatch of preshared key algorithms and a mismatch of preshared key values.

See Crypto Header, in the 7.2.0 RTI Security Plugins User’s Manual for more information.

4.6.5. Allowed Identity Certificate to be mutable

You may now dynamically change your Identity Certificate without having to restart your DomainParticipant. The Identity Certificate is now mutable in two ways:

Changing the value of the dds.sec.auth.identity_certificate property using the DomainParticipant set_qos API. This method works regardless of whether the old or new value of the property has the data:, or file: prefix.

Leaving the value of the dds.sec.auth.identity_certificate property unchanged and instead changing the contents of the actual certificate file. The Security Plugins enforce these changes as long as the com.rti.serv.secure.authentication.identity_certificate_file_poll_period.millisec is set to a value other than 0 (0 is the default). This method works only when the value of the dds.sec.auth.identity_certificate property has the file:, prefix.

As soon as an Identity Certificate change is detected, the Security Plugins will propagate the new certificate to all trusted remote DomainParticipants so that communication with them will not be interrupted when the old certificate expires.

For more information, see Dynamic Certificate Renewal of a DomainParticipant, in the Security Plugins User’s Manual.

4.6.6. Allowed Certificate Revocation List to be mutable

You may now dynamically revoke new DomainParticipants without having to restart your DomainParticipant. The certificate revocation list is now mutable in two ways:

Changing the value of the authentication.crl property using the DomainParticipant set_qos API. This method works regardless of whether the old or new value of the property has the data:, or file: prefix.

Leaving the value of the authentication.crl property unchanged and instead changing the contents of the actual CRL file. The Security Plugins enforce these changes as long as the authentication.crl_file_poll_period.millisec is set to a value other than 0 (0 is the default). This method works only when the value of the authentication.crl property has the file: prefix.

As soon as a CRL change is detected, the Security Plugins will remove any newly revoked remote DomainParticipants.

For more information, see Dynamic Certificate Revocation of Remote DomainParticipants in the Security Plugins User’s Manual.

4.6.7. New example for dynamic certificate revocation and renewal

There is now a C example that demonstrates dynamic certificate revocation and renewal. You can find it in <path to examples>/connext_dds/c/hello_dynamic_certificates. For more information, see Advanced Authentication Concepts, in the RTI Security Plugins User’s Manual.

Third-party Tool	Old Versions	New Version
OpenSSL	1.1.1t, 3.0.8	3.0.9

4. What’s New in 7.2.0

4.1. Changes Related to Interoperability

4.1.1. Support for Connext systems running beyond 2038

4.1.2. Connext Secure integrates with non-compliant DDS Security vendors

4.1.3. Constrained devices running Lightweight Security can now integrate with devices running Security Plugins

4.2. Changes Related to Access Control

4.2.1. Improved endpoint discovery time by removing redundant calling of check_remote_topic

4.2.2. Security Plugins for wolfSSL now support key usage extensions

4.2.3. Secured communications between RTI Monitoring Library 2.0 and RTI Observability Collector Service

4.3. Changes Related to Cryptographic Algorithms

4.3.1. Added Pre-Shared Key Protection to Cloud Discovery Service and Real-Time WAN Transport

4.4. Changes Related to Cryptography

4.4.1. Added unique identifier to pre-shared key property

4.4.2. Added mutability to pre-shared key seed

4.5. Changes Related to Discovery and Authentication

4.5.1. Enabled configuration of protection kind for the builtin service request channel

4.5.2. Support retrieving subject name of a remote DomainParticipant that is not authenticated yet

4.5.3. SPDP2 participant announcements now subject to sample signature verification

4.5.4. Re-validation of remote participant data after authorization

4.5.5. Unauthorized remote participants now removed instead of ignored, allowing for re-authorization

4.6. Changes Related to Dynamic Participant Renewal, Revocation, and Expiration

4.6.1. Dynamically control access to your Connext Secure system using a whitelist of trusted subject names

4.6.2. Added configuration option for certificate expiration notice frequency

4.6.3. Increased robustness against DomainParticipants leaving the system before their certificates become expired or revoked

4.6.4. Improved debuggability, usability, and forward compatibility of Key Revisions

4.6.5. Allowed Identity Certificate to be mutable

4.6.6. Allowed Certificate Revocation List to be mutable

4.6.7. New example for dynamic certificate revocation and renewal

4.7. Changes Related to Platforms and Builds

4.7.1. Support for Security Plugins for wolfSSL 5.5.1 on certain Linux platforms

4.8. Changes Related to Security Plugins SDK

4.8.1. Removed dependency on CMocka third-party library

4.8.2. Added support for building and testing Lightweight Security library

4.8.3. Improved logging during clean up of Security Plugins

4.9. Changes Related to System Extensibility and Configurability

4.9.1. Properties that could increase system vulnerability have been removed

4.10. Changes Related to Third-Party Software

4.10.1. Upgraded OpenSSL to version 3.0.9 and removed OpenSSL 1.1.1 support