DDSSEC11 — Complexity of Authentication Plugin Model

The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

• It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
• The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
• There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
• It is difficult to determine at which sense a received message belongs
• In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

Instead, we suggest to remove it and to change the mechanism to the following:

• remove all the "_handshake" methods on the Authentication Plugin
• add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
• add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
• add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
• add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
• once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

This will provide the necessary functionality in a much simple, efficient and robust manner.

Defer

The issue does not affect the interoperability or behavior. The many benefit would be to simplify the explanation and potentially the implementation of the Authentication plugins. However addressing would be complex in terms of the amount of text that would be affected and the interactions with the text modified by other issues in this RTF.

For this reason it seems most appropriate to defer it to the next RTF. At that point there will be less changes caused by other issues thus simplifying the resolution of this issue