DDS Security Avatar
  1. OMG Specification

DDS Security — Open Issues

  • Acronym: DDS-SECURITY
  • Issues Count: 8
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Allow expressions to be used in the data-tag permissions

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The permissions document allow and deny rules contain a section for matching the data tags of the DataReader/DataWriter. The match is based on an exact match of the tag-name and tag-value.

    For consistency with the way we match the permissions for Topic and Partitions we should also allow an expression for the tag-value portion. This is only for the permission rule itself. Not for the DataTag QosPolicy.

    So to match the rule the DataTag name in the Qos must exactly match the name in the permissions document (no expressions here) and the DataTag value in the Qos should match (using fnmatch) the expression in the permissions document.

  • Reported: DDS-SECURITY 1.1 — Thu, 18 Jan 2018 23:24 GMT
  • Updated: Thu, 18 Jan 2018 23:24 GMT

Authentication interface begin_handshake_reply()

  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Normative IDL has no parameter handshake_message_in (from Table 23). It would be possible to use handshake_message_out to serve the purposes of "in" since it's an inout parameter in IDL, but is that the intention here?

  • Reported: DDS-SECURITY 1.1b1 — Wed, 10 Jan 2018 19:37 GMT
  • Updated: Wed, 10 Jan 2018 19:37 GMT

Define rules for references between elements

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The syntax in DDS-XML containes places where an object references another object. This is done normally using an attribute with type elementNameReference defined in http://www.omg.org/spec/DDS-XML/20170301/dds-xml_domain_definitions_nonamespace.xsd

    However the specification does not deny any rules/constraints on the references themselves. In fact those references must follow a precise syntax to uniquely select an element which require a full path down the containment hierarchy down to the selected element.

    The specification should define this and provide some examples.

  • Reported: DDS-SECURITY 1.1 — Sat, 6 Jan 2018 23:52 GMT
  • Updated: Sat, 6 Jan 2018 23:52 GMT

DataHolder IDL inconsistent

  • Status: open   Implementation work Blocked
  • Source: OCI ( Adam Mitz)
  • Summary:

    In 7.2.3.1, DataHolder is a struct annotated with @extensibility(APPENDABLE) and no optional fields.
    However in ptc/17-09-26 (normative IDL), DataHolder has no @extensibility annotation and two optional fields.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 4 Jan 2018 21:38 GMT
  • Updated: Thu, 4 Jan 2018 21:38 GMT

CryptoTransformIdentifier extensibility FINAL is not compatibly with its derived classes

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 7.3.7.3 defines CryptoHeader as inheriting from CryptoTransformIdentifier. However CryptoHeader is APPENDABLE and CryptoTransformIdentifier is FINAL.

    This does not seem possible according to XTYPES.

    We want CryptoHeader to remain APPENDABLE so we have two choices. Either make CryptoTransformIdentifier also APPENDABLE or re-define CryptoHeader from:

    @extensibility(APPENDABLE)
    struct CryptoHeader : CryptoTransformIdentifier  {
        // Extra plugin-specific information added below
        // CryptoHeader   plugin_crypto_header_extra;
    };
    

    To be:

    @extensibility(APPENDABLE)
    struct CryptoHeader   {
        CryptoTransformIdentifier base;
        // Extra plugin-specific information added below
        // CryptoHeader   plugin_crypto_header_extra;
    };
    

    This second approach would appear to be better as is is wire compatible with the existing definitions.

    This would also affect 9.5.2.3 were it defines the plugin-specifc struct CryptoHeader as:

    // Serialized as Big Endian
    @extensibility(FINAL)
    struct CryptoHeader {
        CryptoTransformIdentifier transform_identifier;
        octet                     session_id[4];
        octet                     initialization_vector_suffix[8];
    };
    

    This would seem inconsistent since we are effectively extending something marked as FINAL.

  • Reported: DDS-SECURITY 1.1 — Sat, 16 Dec 2017 04:11 GMT
  • Updated: Sat, 16 Dec 2017 04:15 GMT

Avoid sending permissions as part of Authentication Handshake

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The authentication handshake requires participants to exchange their permission files. This is done as clear text.

    Visibility into the permissions file leaks information as to what the system Topic names are as well as what the application publishes and subscribes. This can be sensitive for some systems.

    Aside form this sending this document is potentially expensive as the knowledge could be available on a separate channel.

    The RTF should look share this information only with authenticated participants and possibly also avoid sending it if it is already known to the peer participant.

  • Reported: DDS-SECURITY 1.1 — Sat, 18 Nov 2017 00:42 GMT
  • Updated: Sat, 18 Nov 2017 00:46 GMT

Instance-Level access-control

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The Security plugin model supports being able to control access to each DDS Topic instance (instead of just controlling access to the DDS Topic). However the builtin plugin permission files do not provide a way to configure these permissions.

    This is important for many DDS-Security use-cases where each instance represents a different object and needs to separately indicate who has access to it. For example imaging a "CarPosition" topic that is used to publish the position of cars. Someone may be given permission to suscribe or publish its own car position, but not other cars. Likewise a manufactured or insurance company may be given permissions to the cars that they manage but not others.

  • Reported: DDS-SECURITY 1.1 — Fri, 17 Nov 2017 02:07 GMT
  • Updated: Fri, 17 Nov 2017 02:07 GMT

say explicitly that is_valid is set to zero if that is case

  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    At end of 2nd to last para document has (matching the errata):

    "sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid."

    It should probably be

    "sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid set to zero.”

  • Reported: DDS-SECURITY 1.1b1 — Tue, 31 Oct 2017 20:03 GMT
  • Updated: Tue, 31 Oct 2017 20:15 GMT