5.3. Discovery and Authentication

5.3.1. [Critical] Authenticated participant could not replace unauthenticated one if QoS changed during authentication

Regarding the Governance Document tag allow_unauthenticated_participants, the DDS Security 1.2 specification states the following: :

Additionally, a DomainParticipant that later authenticates would kick out the unauthenticated DomainParticipant if it has the same GUID.

The Security Plugins implemented this behavior in Connext 7.3.0, but the following scenario did not work as expected:

  • ParticipantA discovers ParticipantC, which is unauthenticated.

  • Then, ParticipantA discovers ParticipantB, which has the same GUID as ParticipantC.

  • While ParticipantB is in the middle of being authenticated, ParticipantA receives a QoS change from ParticipantC.

In this scenario, when ParticipantB was about to finish being authenticated, ParticipantA incorrectly failed to authenticate ParticipantB and generated a log message similar to this one:

{"plugin_method":"PRESParticipant_authorizeRemoteParticipant"}]}],"m":"authenticated trusted state remote participant aaaaaaaa.bbbbbbbb.ccccccc does not match the one received through discovery by local participant dddddddd.eeeeeeee.ffffffff, removing participant...

Now, a QoS change by ParticipantC does not interfere with the authentication of ParticipantB.

[RTI Issue ID SEC-2738]

5.3.2. [Critical] Unable to communicate with DomainParticipants that propagate a different authentication class_id version

Secure DomainParticipants that had different versions in the class_id of their Authentication plugin failed to communicate.

For example, if a DomainParticipant following the 1.0 DDS Security specification discovered and tried to authenticate a remote DomainParticipant following version 1.2 of the specification, you would see a log message similar to the following:

RTI_Security_Authentication_begin_handshake_reply: received unexpected handshake message, probably from a participant that this one lost liveliness with before ongoing authentication completed. Once this participant sends an authentication request, communication should be restored.
ERROR [[...]|RECEIVE SAMPLE|PROCESS HANDSHAKE|BEGIN HANDSHAKE REPLY|LC:Security] DDS_DomainParticipantTrustPlugins_forwardBeginHandshakeReply:FAILED TO VALIDATE | begin_handshake_reply returned VALIDATION_FAILED..

This release fixes the issue, so a difference in the minor version of the class_id doesn’t prevent communication.

Note that the Builtin Security Plugins 7.3.1 (and later releases) propagate the older DDS:Auth:PKI-DH:1.0 class_id to former RTI releases. This ensures interoperability between RTI releases, even if the older ones are affected by the class_id bug. Interoperability is only broken between releases affected by this bug and other vendors that propagate the newer DDS:Auth:PKI-DH:1.2 class_id.

[RTI Issue ID SEC-2473]