DDSSEC11 — Non Recoverable Communication After Asymmetric Liveliness Loss

After two participants are mutually authenticated and authorized, there are two scenarios that could potentially lead to communication not to recover:

Let's call the Participant sending token1 "requester" and the Participant sending token2 "replier".

Scenario 1

The "replier" participant removes the "requester" participant because of a liveliness loss, there is no way the system can recover:

• Requester participant still knows about the replier (he did not lose the liveliness), so no AI for him.
• Replier participant will wait for a request that will never arrive.

Scenario 2

The "requester" participant removes the "replier" participant because of a liveliness loss, there is no way the system can recover:

• Requester participant sends periodic auth messages (token 1).
• Replier participant still knows about the requester (he did not lose the liveliness), so no AI for him. , It just drop the messages he receives (as if they were duplicates for steps already done) by the replier.

The problem is, there is no standardized mechanism for triggering a new "Figure 9 - Authentication plugin interaction state machine".

Other Scenarios

There may be other scenarios as described in DDSSEC11-81.

Proposal

Add a new mechanism that allow triggering the creation of a new Authentication state machine, as we do when we discover a remote participant. In order to do this in a secure way, we need to keep the old authentication session until this new state machine fully succeeds the authentication process. Also, we need to do this in a way an attacker cannot provoke a Denial of Service Attack by continuously triggering re-authentications.

The proposal here is to solve these problem by adding a new "auth.req" message that asks the remote participant to create a new authentication state machine. If that authentication state machine succeeds, the old one will be replaced:

• Add a new GMCLASSID (“dds.sec.auth.req”) so it is easly identified as a potential request of restarting the whole authentication process for a participant.
• If processed (only if the remote participant is authenticated), this request will trigger the creation of a parallel state for a remote participant. This is, would be equivalent to receive discovery pData from new participant. It will therefore trigger the creation of a new authentication state machine.
• Only if a whole authentication completes, the old remote participant state is removed and the new one triggers the authorization and all the remaining steps.
• For the request, define a new HandshakeMessageToken ("DDS:Auth:PKI-DH:1.0+AuthReq") containing a NONCE.
• That NONCE is the random number the Participant mean to use as part of the challenge process. This will be the same challenge will be used as part of the token1 (or token2) we send.
• Received auth_request will be ignored by peers that are not authenticated with us.
• Received auth_request will be processed by peers fully authenticated with us, used as a hint about the other remote participant could be willing to restart authentication.
• Received NONCE will be compared against the random challenge we will receive in the next token1 (or token2). If that matches, means that the remote participant was the one generating the auth_request, so the authentication can continue. If it does not match, we will return VALIDATION_NOT_OK for that token.
• If the authentication completes, we will remove old state and replace with new one.
• In order to make the above possible, we need to move the generation of the local challenge to the validate_remote_identity step. That will be stored as part of the remote_identity_handle, so it can be used during the authentication process. Also, if the current state machine was triggered by the reception of an auth.request, we need also to store in the remote_identity_handle the "expected" remote challenge.

Define New Authentication Request Mechanism

This proposal will define a new Authentication Request mechanism for requesting for a re-authentication.