1. OMG Mailing List
  2. DDS Security 1.2 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: dds-security-rtf
  • Issues Count: 18

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSSEC12-19 Allow expressions to be used in the data-tag permissions DDS-SECURITY 1.1 open
DDSSEC12-18 Authentication interface begin_handshake_reply() DDS-SECURITY 1.1b1 open
DDSSEC12-16 Define rules for references between elements DDS-SECURITY 1.1 open
DDSSEC12-15 DataHolder IDL inconsistent DDS-SECURITY 1.1b1 open
DDSSEC12-14 CryptoTransformIdentifier extensibility FINAL is not compatibly with its derived classes DDS-SECURITY 1.1 open
DDSSEC12-13 Avoid sending permissions as part of Authentication Handshake DDS-SECURITY 1.1 open
DDSSEC12-12 Instance-Level access-control DDS-SECURITY 1.1 open
DDSSEC12-11 say explicitly that is_valid is set to zero if that is case DDS-SECURITY 1.1b1 open
DDSSEC12-7 The DDS-Security specification makes some modifications to the DDSI-RTPS protocol that should be taken into consideration DDS-SECURITY 1.0 open
DDSSEC12-5 The UML model should be cleaned up DDS-SECURITY 1.0 open
DDSSEC12-9 The specification should not duplicate (copy) the machine readable XSD files DDS-SECURITY 1.0 open
DDSSEC12-8 Section 3 (Normative References) should be updated and expanded DDS-SECURITY 1.0 open
DDSSEC12-10 Issues with the UML model used in the specification DDS-SECURITY 1.0 open
DDSSEC12-6 Remove Jira-issue related comments from machine-readable files DDS-SECURITY 1.0 open
DDSSEC12-2 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 open
DDSSEC12-3 Provide mechanisms to extend Governance and Permissions files without breaking interoperability DDS-SECURITY 1.0b1 open
DDSSEC12-4 Examples of Wildcard permissions DDS-SECURITY 1.0 open
DDSSEC12-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 open

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

The DDS-Security specification makes some modifications to the DDSI-RTPS protocol that should be taken into consideration

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

    The following two sections in DDS-Security 1.1 affect future versions of DDSI-RTPS.

    The DDSI-RTPS should include language that makes sure future versions do not conflict with what DDS-Security and future revisions thereof may do.

    Specifically the following two sections of DDS-Security 1.1 should be taken into consideration

    7.3.6.1 Change to the RTPS minor version number
    Implementations of this specification shall set the RTPS protocol version number present in the RTPS Header. The RTPS Major version number shall be set to 2 and the RTPS Minor version number shall be set to 3. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

    7.4.1.3 Reserved RTPS parameter IDs
    This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range:
    0x1000 to 0x1FFF and 0x5000 to 0x5FFF. The second interval covers the same range of parametersID, except they have the must-understand bit set. This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:48 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

The UML model should be cleaned up

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

    There are some issues with the UML model that should be improved. This came from the AB review of the RTF 1 report:

    ● SubmessageKind should be an Enumeration not a Class. And it’s missing its Literals. Tables 4,5 indicate Literals would include SEC_BODY, SEC_PREFIX, SEC_POSTFIX, SRTPS_PREFIX, SRTPS_POSTFIX
    ● SubmessageFlag is totally underspecified but probably should not be a PrimitiveType
    ● Likewise CryptoState. In fact there are far too many PrimitiveTypes, none of them documented, which should probably be Strings.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 17:53 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

The specification should not duplicate (copy) the machine readable XSD files

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

    The specification contains full copies of the machine readable XSD files:

    • DDS Security Access Control Permissions XSD
    • DDS Security Access Control Governance XSD

    This causes problems as updates may not always be done consistently.

    Therefore it would be better if the specification removed this duplication and just referenced the external machine-readable files.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:30 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

Section 3 (Normative References) should be updated and expanded

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

    The specification depends on many other standards that appear referenced thought the specification and in Annex A (References) but do not appear in Section 3.

    Section 3 should be expanded to include the subset of those references that are used for normative behavior. [46], [47], and [52] are clear examples of references that should be moved to Section 3.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:02 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

Issues with the UML model used in the specification

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

    The UML diagrams in the specification use UML stereotypes, such as <<discovery>>. However these are not documented anywhere in the specification nor do they appear in the XMI.

    Also the diagrams are non-standard UML in that they show superclasses in the top right corner. See for example Figure 10.

    These issues should be corrected.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:07 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

Remove Jira-issue related comments from machine-readable files

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

    The machine-readable files have comments that trace their changes to the Jira issues that caused them. This hurts the use of the specification so they should be removed.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 10:24 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation

  • Key: DDSSEC12-2
  • Status: open  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    An implementation of the built-in Cryptography plugin is not compatible with the local implementation of the built-in Authentication, unless it uses/understands the same type of SharedSecretHandle. (SharedSecretHandle is the interface defined at the architecture level.) Therefore, the two built-in plugins are tied together and you cannot replace one or another with any other implementation of the same built-in plugin.
    It is possible to make them independent in two possible ways (at least):

    1. Define a BuiltinSharedSecretHandle that extends SharedSecretHandle interface, and has 3 methods like this:
      • octet[] getChallenge1(): returns challenge1 from the authentication handshake
      • octet[] getChallenge2(): returns challenge2 from the authentication handshake
      • octet[] getSharedSecret(): returns the shared secret from the authentication handshake
    2. OR define a new type of Token (IDL structure) - e.g. HandshakeResultToken - for the final output of the Authentication handshake like this:
      • class_id DDS:Auth:PKI-DH:1.0+Result
      • binary_properties: challenge1, challenge2, SharedSecret

    In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.

  • Reported: DDS-SECURITY 1.0b1 — Tue, 1 Mar 2016 17:36 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT

Provide mechanisms to extend Governance and Permissions files without breaking interoperability

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

    The specification does not state what to do when Permissions and Governance files contain "extra elements" that are not valid according to the XSD.

    This is expected to occur both as a result of vendor extensions as well as due to additions in future versions of DDS Security.

    Allowing these extensions/additions without breaking compatibility is important. So the spec should be clear in that they are allowed and also provide rules/guidelines on them.

    Some possibilities:

    • Simply state that elements that are not expected/understood should be ignored
    • Same as above but provide some structure for those elements. E.g. specify that they must have a "vendorId" attribute (used to avoid collisions) and a "mustUnderstand" attribute used to force failure in some cases.
    • Define an "extensions" element that has known structure (e.g. name/value pairs) which is the one used for the extensions.
    • Others to be proposed.

    Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/

  • Reported: DDS-SECURITY 1.0b1 — Sat, 20 Feb 2016 01:36 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT
  • Attachments:

Examples of Wildcard permissions

  • Key: DDSSEC12-4
  • Status: open  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    It is not clear whether the Permissions XSD allows to express all kinds of wildcard permissions. Just to make sure we cover all cases, we should give examples of permissions XML that grant only...

    1. all permissions to any domain? ("all permissions" = join, pub/sub/relay to any topic/partition/data_tag, etc.)
    2. all permissions to a specific domain, e.g. domain 0?
    3. all permissions to all topics of domain 0? ("all permissions" = pub/sub/relay, etc.)
    4. all permissions to all partitions of domain 0?
    5. all permissions to a specific topic, e.g. "Circle1", of domain 0?
    6. all permissions to a specific partition, e.g. "P1", of domain 0?
    7. the permission to publish to any topic of domain 0? (but not subscribe/relay)
    8. the permission to publish to any partition of domain 0? (but not subscribe/relay)

    Such examples would be very useful in the spec as well.

  • Reported: DDS-SECURITY 1.0 — Tue, 11 Jul 2017 12:43 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT
  • Attachments:

Complexity of Authentication Plugin Model

  • Key: DDSSEC12-1
  • Legacy Issue Number: 19793
  • Status: open  
  • Source: PrismTech ( Julien Enoch)
  • Summary:

    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.

  • Reported: DDS-SECURITY 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Updated: Mon, 16 Oct 2017 15:36 GMT