5.2. Discovery and Authentication
5.2.1. [Critical] Participant discovery failed to complete after re-authentication when using SPDP2 *
If an asymmetric liveliness occurred between two participants P1 and P2 where P1 lost liveliness with P2, P1 would remove the associated states but P2 would keep the authenticated state. P2 could re-authenticate P1 if P1 sent it an Authentication Request message. Participants using SPDP2 would not complete re-discovery after re-authentication completed and communication would not be possible.
[RTI Issue ID SEC-2336]
5.2.3. [Major] allow_unauthenticated_participants did not allow authenticated participant to replace unauthenticated one
The DDS Security 1.2 specification has this sentence about the
Governance Document tag allow_unauthenticated_participants:
Additionally, a DomainParticipant that later authenticates would kick out the unauthenticated DomainParticipant if it has the same GUID.
The Security Plugins did not implement this behavior. The
authentication attempt from the new DomainParticipant was incorrectly
ignored. Now, this behavior works as long as the
DomainParticipantQos property
dds.participant.discovery_config.use_stateless_participant_discovery_reader
is set to TRUE.
For details about the new behavior, see allow_unauthenticated_participants (domain_rule) in the RTI Security Plugins User’s Manual.
[RTI Issue ID SEC-1660]
5.2.4. [Major] Participants with SPDP2 failed to complete discovery if using Lightweight Builtin Security Plugins or HMAC-only mode *
Participants using SPDP2 failed to complete participant discovery if they were also using the Lightweight Builtin Security Plugins, or the Builtin Security Plugins with HMAC-only mode. This has been resolved and participants with SPDP2 can now use the Lightweight Builtin Security Plugins or HMAC-only mode.
[RTI Issue ID SEC-2338]
5.2.5. [Major] Participants with SPDP2 and allow_unauthenticated_participants failed to communicate if authentication failed *
Participants using SPDP2 with allow_unauthenticated_participants set
to TRUE failed to communicate if both participants were using security
and authentication failed. This has been resolved for the case where
both participants have allow_unauthenticated_participants set to
TRUE and both participants fail authentication. In this case,
communication between the participants will proceed for all non-secure
topics.
[RTI Issue ID SEC-2340]
5.2.6. [Major] Errors setting the RSA padding kind did not trigger a failure in signing or verifying DomainParticipant data *
If the authentication.rsa_pss_pad plugin-specific property is set to
AUTO or TRUE, then the DomainParticipant may:
Use RSA_PKCS1_PSS_PADDING padding when signing messages (depending on the Identity Certificate).
Accept RSA_PKCS1_PSS_PADDING padding when verifying the remote DomainParticipant’s signed messages.
Signing and verifying messages should fail if there are errors when
setting the right RSA padding. This was not the case for previous
releases of the Security Plugins (7.0, 7.1, and 7.2). The Builtin
Security Plugins logged
RTI_Security_CertHelper_setRsaPadding:OpenSSL function EVP_PKEY_CTX_set_rsa_mgf1_md failed with error
when they couldn’t set the RSA padding kind, but the sign/verify process
continued. As a consequence, the signature type may not have been the
one the user expected. This release of the Security Plugins fixes the
issue. Errors in setting the RSA padding kind during signing or
verifying a message result in a failure.
[RTI Issue ID SEC-2392]
5.2.7. [Minor] Failure to announce lack of PSS Padding support when authentication.rsa_pss_pad property was FALSE *
When the authentication.rsa_pss_pad property is set to FALSE in
the Builtin Security Plugins, the associated DomainParticipant is
expected to announce through discovery the lack of support for the
RSASSA-PSS-MGF1SHA256+2048+SHA256 algorithm to other
DomainParticipants. Security Plugins 7.0, 7.1, and 7.2 had a bug in
this mechanism. As a result, two incompatible DomainParticipants may
have incorrectly matched during discovery. Then these
DomainParticipants would have tried to authenticate, resulting in a
failed authentication.
In previous releases, you could have worked around this issue by
configuring the <allowed_security_algorithms> tag in your Governance
Document, and omitting RSASSA-PSS-MGF1SHA256+2048+SHA256 in your
<digital_signature_identity_trust_chain> algorithms. The workaround
is no longer necessary.
[RTI Issue ID SEC-2394]
* This bug does not affect you if you are upgrading from 6.1.x or earlier.