DDS-SECURITY 1.1 RTF Avatar
  1. OMG Issue

DDSSEC11 — Clarify whether governance settings for a DataWriter and a DataReader must be consistent for a match to occur

  • Key: DDSSEC11-38
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not clarify what happens in a situation where a DataReader governance specifies one thing (e.g. Encrypted Payload) and the DataWriter governance something else (e.g. signing only).

    It may be advisable to consider this as some kind of "Qos mismatch" that prevents the DataWriter from matching the DataReader. Either way the behavior needs to be clearly spelled out.

    Furthermore currently the DataWriter does not send to the DataReader its Governance, nor any information regarding the crypto transformations applied. This would seem a weakness that could be exploited.

    When processing the submessage payload the DataReader could apply its local governance. Since it knows it is supposed to be encrypted/signed and who the DataWriter is it can then use the cryptphandle for that DataWriter. So in this case it seems like we should enforce matching only DataWriters that have a "compatible" treatment of the serialized payload. But to do this we should know at matching time whether the DataWriter intends to encrypt/sign or not.

    When processing a submessage "SEC_PREFIX" we do not know who the sender was... So we do not know how to treat it, all we can do is try to decrypt it. But after that is done it should verify that the GUID of the DataWriter is consistent with the datawriter_cryptohandle used to decrypt the message.

    Similarly we need some mechanism to enforce the governance of the discovered endpoints. Basically if a Topic should be sent via secure discovery but it is received via the regular discovery then it should be rejected. Implementing this would require a "is_discovery_protected" EndpointSecurityAttributes (see DDSSEC11-16)

  • Reported: DDS-SECURITY 1.0 — Wed, 19 Oct 2016 15:01 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define PID for Sending Endpoint Security Attributes

    This will define a new PID for sending the Endpoint Security attributes, so it is possible to do endpoint matching decisions based on the attributes.

    Note: current specification defines is_payload_protected. If this proposal is to be accepted, we will need to create an issue for that.

  • Updated: Tue, 19 Dec 2017 20:03 GMT