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

Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSSEC12-32 Authentication behavior use of built-in endpoints DDS-SECURITY 1.1b1 open
DDSSEC12-58 AES-GCM doesn't add padding DDS-SECURITY 1.1b1 open
DDSSEC12-80 Add support for ChaCha20 DDS-SECURITY 1.1b1 open
DDSSEC12-79 Built-in Access Control: interpretation of enable_read/write_access_control DDS-SECURITY 1.1 open
DDSSEC12-42 Various Typos DDS-SECURITY 1.1b1 open
DDSSEC12-13 Avoid sending permissions as part of Authentication Handshake DDS-SECURITY 1.1 open
DDSSEC12-77 Invalid IETF RFC document reference. DDS-SECURITY 1.1b1 open
DDSSEC12-75 Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types DDS-SECURITY 1.1b1 open
DDSSEC12-76 IDL should be updated to match IDL 4.2 DDS-SECURITY 1.1b1 open
DDSSEC12-74 Builtin Access Control operations (Table 63) missing entries DDS-SECURITY 1.1 open
DDSSEC12-73 Multiple grants in a permissions document DDS-SECURITY 1.1b1 open
DDSSEC12-72 serialized_local_participant_data passed to Auth plugin DDS-SECURITY 1.1b1 open
DDSSEC12-71 Inconsistent descriptions of Data Tagging DDS-SECURITY 1.1b1 open
DDSSEC12-70 Protecting the Source Timestamp DDS-SECURITY 1.1b1 open
DDSSEC12-69 Builtin Auth dependency on Access Control details DDS-SECURITY 1.1b1 open
DDSSEC12-68 Add explanation of how to use the secureWriterSet to support GROUP ordered access DDS-SECURITY 1.1b1 open
DDSSEC12-67 Misleading description of Crypto Key Exchange (8.5.1.8) DDS-SECURITY 1.1b1 open
DDSSEC12-66 IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties DDS-SECURITY 1.1b1 open
DDSSEC12-65 validate_remote_permissions interaction with Authentication Plugin DDS-SECURITY 1.1b1 open
DDSSEC12-64 get_topic_sec_attributes 3rd parameter type DDS-SECURITY 1.1b1 open
DDSSEC12-63 Operation: set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC12-62 Indicate that AccessControl operations need to be called on a set_qos DDS-SECURITY 1.1b1 open
DDSSEC12-49 Mutability of PartitionQos DDS-SECURITY 1.1b1 open
DDSSEC12-61 Table 29 description of is_write_protected DDS-SECURITY 1.1b1 open
DDSSEC12-60 check_remote_topic domainId parameter DDS-SECURITY 1.1b1 open
DDSSEC12-59 Parsing messages generated by encode_serialized_payload (auth only) DDS-SECURITY 1.1b1 open
DDSSEC12-57 Builtin Crypto message authentication codes DDS-SECURITY 1.1b1 open
DDSSEC12-56 Encoding of Diffie-Hellman Public Key DDS-SECURITY 1.1b1 open
DDSSEC12-55 Using string literals as binary_property values inside Handshake Tokens DDS-SECURITY 1.1b1 open
DDSSEC12-54 XML Schema defines boolean literals as "true" / "false" DDS-SECURITY 1.1b1 open
DDSSEC12-53 Specify number of constant bytes in HMAC input when computing SessionKey DDS-SECURITY 1.1b1 open
DDSSEC12-52 9.5.3.3.4.3 should refer to the footer, not header DDS-SECURITY 1.1b1 open
DDSSEC12-51 Participant2ParticipantKxKeyMaterial DDS-SECURITY 1.1b1 open
DDSSEC12-50 Builtin CryptoKeyFactory direct dependency on AccessControl's config details DDS-SECURITY 1.1b1 open
DDSSEC12-30 8.4.2.9.24 section name typo DDS-SECURITY 1.1b1 open
DDSSEC12-46 "atributes" typo DDS-SECURITY 1.1b1 open
DDSSEC12-48 Clarify the configuration and use of certificate chains for Identity DDS-SECURITY 1.1b1 open
DDSSEC12-41 Reduce the range of Reserved RTPS parameter IDs DDS-SECURITY 1.1b1 open
DDSSEC12-47 Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED DDS-SECURITY 1.1b1 open
DDSSEC12-38 Broken cross-references DDS-SECURITY 1.1b1 open
DDSSEC12-45 Replace "CryptoKeyTransform" with "CryptoTransform" DDS-SECURITY 1.1b1 open
DDSSEC12-44 register_local_datareader and Data Protection Kind DDS-SECURITY 1.1b1 open
DDSSEC12-43 IDL ParticipantSecurityAttributes::plugin_participant_attributes DDS-SECURITY 1.1b1 open
DDSSEC12-40 Return types in CryptoKeyFactory interface description DDS-SECURITY 1.1b1 open
DDSSEC12-39 AuthRequestMessageToken future_challenge property DDS-SECURITY 1.1b1 open
DDSSEC12-2 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 open
DDSSEC12-37 Modify Security's QoS changes for compatibility with RTPS DDS-SECURITY 1.1b1 open
DDSSEC12-36 Description of the EndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC12-35 Description of the PluginEndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC12-34 Wrong XML tag in description of Enable Read Access Control DDS-SECURITY 1.1b1 open
DDSSEC12-33 Use a submessage flag to indicate Data/Frag submessage has a transformed payload DDS-SECURITY 1.1b1 open
DDSSEC12-31 Security for DDS-RPC DDS-SECURITY 1.1b1 open
DDSSEC12-25 IDL get_topic_sec_attributes parameter typo DDS-SECURITY 1.1b1 open
DDSSEC12-29 Specify DDS Security uses XCDR serialization version 1 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-28 Determining when to use DCPSParticipantMessageSecure DDS-SECURITY 1.1b1 open
DDSSEC12-27 ParticipantStatelessMessage definition DDS-SECURITY 1.1b1 open
DDSSEC12-26 IDL SubscriptionBuiltinTopicDataSecure inheritance DDS-SECURITY 1.1b1 open
DDSSEC12-24 IDL LongLongSeq unused DDS-SECURITY 1.1b1 open
DDSSEC12-23 Authentication interface set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC12-22 get_datawriter/reader_sec_attributes inconsistent IDL DDS-SECURITY 1.1b1 open
DDSSEC12-21 decode_datawriter_submessage uses "in" for SecurityException DDS-SECURITY 1.1b1 open
DDSSEC12-20 SecureSubmessageCategory_t in normative IDL DDS-SECURITY 1.1b1 open
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-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-5 The UML model should be cleaned up DDS-SECURITY 1.0 open
DDSSEC12-6 Remove Jira-issue related comments from machine-readable files DDS-SECURITY 1.0 open
DDSSEC12-9 The specification should not duplicate (copy) the machine readable XSD files DDS-SECURITY 1.0 open
DDSSEC12-10 Issues with the UML model used in the specification DDS-SECURITY 1.0 open
DDSSEC12-8 Section 3 (Normative References) should be updated and expanded DDS-SECURITY 1.0 open
DDSSEC12-4 Examples of Wildcard permissions DDS-SECURITY 1.0 open
DDSSEC12-3 Provide mechanisms to extend Governance and Permissions files without breaking interoperability DDS-SECURITY 1.0b1 open
DDSSEC12-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 open

Issues Descriptions

Authentication behavior use of built-in endpoints

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

    In section 8.8.2.2, it's established that the BuiltinParticipantStatelessMessage built-in endpoints are used for exchanging the "authentication handshake" messages. This makes sense based on how those built-in endpoints are defined in 7.4.3 and how they're used in some parts of 8.3.2.9 and .11.

    However there are parts of 8.3.2.11 and 8.8.2 that describe this handshake using the names BuiltinParticipantMessageWriter / Reader (note the absence of "Stateless"). The name BuiltinParticipantMessageWriter is defined by the RTPS spec as the endpoint used to implement the participant scoped liveliness (see RTPS 2.2 section 8.4.13.2).

  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:41 GMT
  • Updated: Thu, 4 Apr 2019 17:20 GMT

AES-GCM doesn't add padding

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

    In 9.5.3.3.4.2 remove this part:
    "Note that the cipher operations have 16-byte block-size and add padding when needed. Therefore the secure data.length (“N”) will always be a multiple of 16."

    AES-GCM doesn't add padding. The implication of this is that the CryptoContent Submessage Element may end at an arbitrary point in the stream (from the point of view of alignment). Bringing the stream "back into alignment" will depend on the usage context:

    • When encoding payload, the CryptoFooter follows directly after CryptoContent. This means that CryptoFooter's first element (common_mac) may start unaligned. Then receiver_specific_macs.length appears in the stream as a 32-bit value so it will be preceded by 0-3 padding bytes depending on the length of CryptoContent.
    • When encoding a submessage or full message, CryptoContent is followed by the start of another submessage which must be aligned to 4 per the RTPS spec.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 1 May 2018 15:10 GMT
  • Updated: Sat, 16 Mar 2019 05:47 GMT

Add support for ChaCha20

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

    The AES-CCM cypher suite used by the built-in authentication plugins is well suited for higher end processors that have hardware support for AES (e.g. the Intel AES-NI instructions and the the AES instructions in ARMv8).

    ARMv7 and other low-end processors don't have hardware support. In these AES can be quite slow.

    To better support lower end processors it would be good to add support for a cypher suite that has reasonable performance without hardware support. The industry seems to be converging around the ChaCha20. See:

    https://tools.ietf.org/html/rfc8439
    https://tools.ietf.org/html/rfc7905

    Gerardo

  • Reported: DDS-SECURITY 1.1b1 — Sat, 16 Mar 2019 05:31 GMT
  • Updated: Sat, 16 Mar 2019 05:31 GMT

Built-in Access Control: interpretation of enable_read/write_access_control

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

    The check_create_participant entry of "Table 63 - Actions undertaken..." in the case where is_access_protected is true and all topic entries in Governance have enable_read_access_control and enable_write_access_control both true specifies that check_create_participant returns false. Thus the participant can't be created and this configuration won't be usable.

    If the intent of enable_read/write_access_control is to defer to the Permissions document to determine both readability and write-ability of this participant (for the given topic) it would seem like this case should be supported and allowed by check_create_participant.

  • Reported: DDS-SECURITY 1.1 — Fri, 16 Nov 2018 23:24 GMT
  • Updated: Fri, 16 Nov 2018 23:24 GMT

Various Typos

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

    Section 7.4.4.2 "TopicSecurityAtributes" should be "Attributes"

    Section 8.8.9.1, 8.8.9.2, and 8.8.9.3 "cripto" should be "crypto"

    Section 8.8.3 "best-efforts" should be "best-effort"

    Section 8.8.4 "simultanepusly" should be "simultaneously"

    Table 63 caption: "bulitin" should be "built-in"

    Section 9.5 "BEST_EFFORTS" should be "BEST_EFFORT"

    Section 9.5.2.3 "indentifier" should be "identifier"

    Section 9.5.3.1 "ciphetext' should be "ciphertext"

    Normative IDL parameter 1 of create_local_data_crypto_tokens "cryto" should be "crypto"

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 17:02 GMT
  • Updated: Fri, 16 Nov 2018 23:13 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.

    Related this is the fact that permissions are "monolithic" of you need to add a permission to a Participant you need to create and sign a new document. Would be nice to have some way to grant/propagate incremental permissions. E.g. something that could be bundled into the propagation of the Endpoint discovery data itself.

  • Reported: DDS-SECURITY 1.1 — Sat, 18 Nov 2017 00:42 GMT
  • Updated: Tue, 9 Oct 2018 15:29 GMT

Invalid IETF RFC document reference.

  • Status: open  
  • Source: ADLINK Technology Ltd ( Erik Hendriks)
  • Summary:

    The "Domain Governance Document" and "DomainParticipant permissions document" chapters contain references to "IETF RFC 5761". This doesn't seem correct.

    It seems that it should be "IETF RFC 2633". At least then the mentioned RFC sections fit.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 4 Sep 2018 10:56 GMT
  • Updated: Tue, 4 Sep 2018 10:56 GMT

Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types

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

    Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

    @Choice @Autoid
    struct RobotControl_command_Result { 
        RobotControl_command_Out result;
    };@Choice @Autoid
    struct RobotControl_stop_Result { 
        RobotControl_getSpeed_Out result;
    };
    };@Choice @Autoid
    struct RobotControl_setSpeed_Result {
          RobotControl_setSpeed_Out result;
          TooFast toofast_ex;
    };
    };@Choice @Autoid
    struct RobotControl_getSpeed_Result {
          RobotControl_getStatus_Out result;
    };
    

    This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places. The correct IDL would be:

    @Choice @Autoid
    struct RobotControl_command_Result { 
        RobotControl_command_Out result;
    };
    
    @Choice @Autoid
    struct RobotControl_stop_Result { 
        RobotControl_getSpeed_Out result;
    };
    
    @Choice @Autoid
    struct RobotControl_setSpeed_Result {
          RobotControl_setSpeed_Out result;
          TooFast toofast_ex;
    };
    
    @Choice @Autoid
    struct RobotControl_getSpeed_Result {
          RobotControl_getStatus_Out result;
    };
    
  • Reported: DDS-SECURITY 1.1b1 — Wed, 29 Aug 2018 00:41 GMT
  • Updated: Wed, 29 Aug 2018 14:02 GMT

IDL should be updated to match IDL 4.2

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

    The IDL used by the specification should be updated to the latest IDL 4.2 syntax.

    This specially impacts annotations. For example @Extensibility(MUTABLE_EXTENSIBILITY) has been replace with @mutable.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 29 Aug 2018 00:44 GMT
  • Updated: Wed, 29 Aug 2018 00:44 GMT

Builtin Access Control operations (Table 63) missing entries

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

    The operations get_datareader_sec_attributes and get_datawriter_sec_attributes are missing from Table 63 - Actions undertaken by the operations of the bulitin AccessControl plugin.

  • Reported: DDS-SECURITY 1.1 — Mon, 27 Aug 2018 22:12 GMT
  • Updated: Mon, 27 Aug 2018 22:12 GMT

Multiple grants in a permissions document

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

    There is only one <permissions> element in a permissions document, but it can contain multiple <grant> elements. Section 9.4.1.3.2.1 states "Each subject name can only appear in a single <permissions> Section"... which should be "single <grant> Section" and "A permissions Section with a subject name that doesn't match" should be "A grant Section with a subject name that doesn't match."

  • Reported: DDS-SECURITY 1.1b1 — Mon, 20 Aug 2018 15:41 GMT
  • Updated: Mon, 20 Aug 2018 15:41 GMT

serialized_local_participant_data passed to Auth plugin

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

    When the middleware calls Auth plugin operations begin_handshake_request and begin_handshake_reply, it must provide serialized_local_participant_data as an OctetSeq according to serialization rules described in 8.3.2.11.4-5. However, these sections do not specify that padding bytes in the serialized data should be initialized to 0. This is desirable so that the OctetSeq can be hashed with consistent results.

    Alternatively, revisit the choice to use OctetSeq here in the plugin API. It seems like it would be fine to pass the structure ParticipantBuiltInTopicDataSecure directly to the plugin, as is already done with Access Control.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 9 Aug 2018 16:01 GMT
  • Updated: Thu, 9 Aug 2018 16:01 GMT

Inconsistent descriptions of Data Tagging

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

    Section 8.7 specifies the optional Data Tagging model, but the details of how this works really reside in the Access Control plugin. Sections 1.2 and 2.3 need to be updated to remove references to a Data Tagging "Plugin." Also update section 8.1.1. For clarity, update section 8.7.2 to add a reference to Access Control.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 6 Aug 2018 16:58 GMT
  • Updated: Mon, 6 Aug 2018 17:01 GMT

Protecting the Source Timestamp

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

    Currently the INFO_SOURCE can only be protected by RTPS protection. This makes anyone on the Domain able to modify it. Moreover it must be left unprotected when communicating with unsecured participants.

    It would be better if it was included into the DATA / DATA_FRAG submessge as an inlineQos

  • Reported: DDS-SECURITY 1.1b1 — Fri, 27 Jul 2018 12:32 GMT
  • Updated: Fri, 27 Jul 2018 12:32 GMT

Builtin Auth dependency on Access Control details

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

    (This may be a moot point depending on the resolution of DDSSEC12-13.)

    The row of Table 52 that describes validate_local_identity states that the QoS it receives must contain the properties defined in section 9.3.1. These properties are the ones starting with dds.sec.auth.

    The problem is that for begin_handshake_* (either variant) to work, validate_local_identity must also receive the property dds.sec.access.permissions. This should be noted in the requirements for validate_local_identity: it must store the QoS, or at least this property, in a location that can be looked up by IdentityHandle so that handshake tokens can be created. Alternatively, the begin_handshake_* operations could be extended to receive this info separately.

    Another connection between the two plugins is made by the PermissionsCredentialToken. If the intent is to use this data when generating handshake handles, that should be noted in tables 49-50 (c.perm) instead of referencing QoS policies there.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 23 Jul 2018 16:19 GMT
  • Updated: Mon, 23 Jul 2018 16:41 GMT

Add explanation of how to use the secureWriterSet to support GROUP ordered access

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

    RTPS 2.4 added support for GROUP ordered access and coherent access. Part of this work added fields to the heartbeat submessage, one of which is a secureWriterSet.

    This field shall contain the 32-bit xxHash32 of all of the writer EntityIds that are sent via secure discovery.

    The use of this field should be mentioned somewhere in the security spec as the RTPS spec refers to the security specification to define the use of this field.

    A new inline QoS was also added: PID_SECURE_WRITER_GROUP_INFO. This inline QoS should also be added to the security spec.

    See the revised RTPS text here: DDSIRTP23-117

  • Reported: DDS-SECURITY 1.1b1 — Fri, 20 Jul 2018 16:44 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

Misleading description of Crypto Key Exchange (8.5.1.8)

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

    Section 8.8.9 specifies that when the crypto tokens are sent on the network,
    BuiltinParticipantVolatileMessageSecureWriter is used so they are not sent in the clear. This detail is also described in 8.5.1.8.1 and other parts of 8.5.1.8.

    Section 8.5.1.8.1 (2nd pgh) contains
    ...intended for transmission in "clear text" to the remote...
    which contradicts 8.8.9.

    To resolve this issue, remove a few unnecessary parts of 8.5.1.8:

    • 8.5.1.8.1 2nd sentence of 2nd pgh "The returned CryptoToken sequence is intended..."
    • 8.5.1.8.2 latter half of 2nd pgh starting "The CryptoToken sequence may contain..."
    • 8.5.1.8.4 (similar content to 8.5.1.8.2)
    • 8.5.1.8.6 (similar content to 8.5.1.8.2)
  • Reported: DDS-SECURITY 1.1b1 — Fri, 13 Jul 2018 17:02 GMT
  • Updated: Fri, 13 Jul 2018 17:02 GMT

IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties

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

    The name of field ac_endpoint_properties in ParticipantSecurityAttributes should be ac_participant_properties as specified in Table 27.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Jul 2018 16:47 GMT
  • Updated: Wed, 11 Jul 2018 16:47 GMT

validate_remote_permissions interaction with Authentication Plugin

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

    Table 63's entry for validate_remote_permissions describes a required interaction with the authentication plugin in order to obtain an AuthenticatedPeerCredentialToken. This appears to be an artifact of a previous spec revision, since the current API for validate_remote_permissions already provides the AuthenticatedPeerCredentialToken.

    So that validate_remote_permissions makes more sense, remove the auth_plugin and remote_identity_handle parameters (Table 32, section 8.4.2.9.2, Table 63, IDL).

  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:56 GMT
  • Updated: Fri, 6 Jul 2018 21:56 GMT

get_topic_sec_attributes 3rd parameter type

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

    In the IDL get_topic_sec_attributes's 3rd parameter has type TopicSecurityAttributes. In table 32 it appears as EndpointSecurityAttributes which seems to be an error.

    Also Figure 10 calls this method get_topic_security_attributes instead of using "sec".

  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:47 GMT
  • Updated: Fri, 6 Jul 2018 21:47 GMT

Operation: set_permissions_credential_and_token

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

    Section 8.3.2.11.11 has no description of the permissions_token parameter

  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:42 GMT
  • Updated: Fri, 6 Jul 2018 21:42 GMT

Indicate that AccessControl operations need to be called on a set_qos

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

    The operations
    check_create_participant
    check_create_datawriter
    check_create_datareader
    check_remote_participant
    check_remote_datawriter
    check_remote_datareader
    check_local_datawriter_match
    check_local_datareader_match

    Should be called when the Qos (or the discovery XXXBuiltinTopicData) change for the one of the involved entities.

    This should be added to the proper 8.4.2.9.x sections.

  • Reported: DDS-SECURITY 1.1b1 — Sat, 9 Jun 2018 00:16 GMT
  • Updated: Sat, 9 Jun 2018 00:16 GMT

Mutability of PartitionQos

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

    In 7.3.5 (Immutability of Publisher Partition Qos in combination with non-volatile...)

    The criteria (1) is not consistent with the goal stated at the end of the section about "prevents data that was published while the DataWriter had associated a set of Partitions from being sent to DataReaders that were not matching before the Partition change and match after the Partition is changed."

    To accomplish this criteria (1) should be re-stated to say this impacts if the Topic associated with the DataWriter has TopicSecurityAttributes with is_read_protected set to TRUE.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 10 Apr 2018 00:03 GMT
  • Updated: Sat, 9 Jun 2018 00:04 GMT

Table 29 description of is_write_protected

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

    The description of is_write_protected starts with "Indicates if read access". This should be "Indicates if write access."

  • Reported: DDS-SECURITY 1.1b1 — Thu, 31 May 2018 16:49 GMT
  • Updated: Thu, 31 May 2018 16:49 GMT

check_remote_topic domainId parameter

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

    domainId is not listed in section 8.4.2.9.12

  • Reported: DDS-SECURITY 1.1b1 — Thu, 10 May 2018 15:06 GMT
  • Updated: Thu, 10 May 2018 15:06 GMT

Parsing messages generated by encode_serialized_payload (auth only)

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

    When "performing authentication only," the encode_serialized_payload operation wraps the SerializedPayload inside CryptoHeader and CryptoFooter. This resulting byte stream takes the place of the original SerializedPayload submessage element in a Data(Frag) submessage.

    On the receiving side, this modified submessage element is passed to decode_serialized_payload. The problem comes in parsing this CryptoHeader-SeralizedPayload-CryptoFooter group.

    The CryptoHeader is of fixed size and only contains octet-width data (therefore has no padding), so parsing it and determining where SerializedPaylod starts is trivial.

    Then the implementation needs to determine where SerializedPayload ends in order to determine which bytes to authenticate. There is no in-stream indication of where the SerializePayload ends.

    One possibility would be to look at the end of the byte sequence that decode_serialized_payload received and "step backwards" by the length of the CryptoFooter, however the CryptoFooter is variable length (with receiver_specific_macs). Even if the implementation has external knowledge that receiver_specific_macs are not in use, the alignment requirement of the plugin_sec_tag.receiver_specific_macs.length effectively makes this a variable-length element (also see issue #58).

    To resolve this, an additional element for "length" could be added before the SerializedPayload, just like the CryptoContent submessage element does. This would make parsing the encoded payload similar for the encrypt and auth-only cases.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 9 May 2018 15:38 GMT
  • Updated: Wed, 9 May 2018 15:38 GMT

Builtin Crypto message authentication codes

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

    9.5.3.3.6 "The message digest is computed on the crypto_header and the ciphertext."

    This statement appears to contradict the descriptions of common_mac and receiver_specific_macs in 9.5.3.3.4.4 (payload), 9.5.3.3.4.5 (submessage), and 9.5.3.3.4.6 (message).

  • Reported: DDS-SECURITY 1.1b1 — Thu, 19 Apr 2018 20:58 GMT
  • Updated: Thu, 19 Apr 2018 20:58 GMT

Encoding of Diffie-Hellman Public Key

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

    The HandshakeRequestMessageToken's dh1 property (Table 49) contains a Diffie-Hellman Public Key. The text of Table 49 says that this is encoded as a CDR Big Endian Serialization. However, the data type of the Public Key is neither a CDR Built-In type nor specified in IDL. Thus the encoding is underspecified.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 18:33 GMT
  • Updated: Wed, 11 Apr 2018 18:33 GMT

Using string literals as binary_property values inside Handshake Tokens

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

    In the definition of the various Handshake Tokens, certain property values are specified with literal strings in the spec (such as "RSASSA-PSA-SHA256"). Since these are inserted into binary_properties, the spec should describe the encoding: is there a length prefix (like CDR string?), is there a trailing nul (like CDR string?), assume the encoding is ASCII but it would be good to specify this.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 18:24 GMT
  • Updated: Wed, 11 Apr 2018 18:24 GMT


Specify number of constant bytes in HMAC input when computing SessionKey

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

    The string literal "SessionKey" (and "SessionReceiverKey") is used without additional context as part of the binary input to HMAC. Add to this section that the ASCII encoding of "SessionKey" without a nul terminator is required.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 18:07 GMT
  • Updated: Wed, 11 Apr 2018 18:07 GMT

9.5.3.3.4.3 should refer to the footer, not header

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

    The last paragraph of 9.5.3.3.4.3 refers to the "CryptoHeader", this should be "CryptoFooter"

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:48 GMT
  • Updated: Wed, 11 Apr 2018 16:48 GMT

Participant2ParticipantKxKeyMaterial

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

    Table 70 introduces the term "Participant2ParticipantKxKeyMaterial" which isn't used anywhere else in the spec.

    It would be helpful to have a table that lists each "key material" object along with which operation creates it and how it's used.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:45 GMT
  • Updated: Wed, 11 Apr 2018 16:45 GMT

Builtin CryptoKeyFactory direct dependency on AccessControl's config details

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

    The behavior of the built-in CryptoKeyFactory operations is described in Table 70. Many entries of this table include direct references to details of the built-in Access Control plugin's configuration file (an example, "see 9.4.1.2.5.6").

    It would be easier to follow and more modular if this was changed to instead reference the data structure that the CryptoKeyFactory can actually see, which in this case is ParticipantSecurityAttributes.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:41 GMT
  • Updated: Wed, 11 Apr 2018 16:41 GMT

8.4.2.9.24 section name typo

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

    Operation: get_datarwriter_sec_attributes
    should be
    Operation: get_datawriter_sec_attributes

  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Feb 2018 20:34 GMT
  • Updated: Wed, 11 Apr 2018 16:31 GMT

"atributes" typo

  • Status: open  
  • Source: OCI ( Tim Simpson)
  • Summary:

    participant_security_attributes is currently spelled participant_security_atributes on page 25 of the specification.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:57 GMT
  • Updated: Wed, 11 Apr 2018 16:27 GMT

Clarify the configuration and use of certificate chains for Identity

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

    Section 9.3.1.3 (Identity Certificate) indicates it is possible to use certificate chains.

    However the language of this section is confusing because an X.509 v3 Certificate does not contain a chain. It is a single certificate. What can contain a chain of certificates is a file. E.g. the standard "PEM" file format referenced in Table 44 can contain a certificate chain.

    To clarify this the following modifications are suggested:
    (1) In table 44, row for "identity_certificate" change from:
    "URI to a X509 certificate signed by the IdentityCA in PEM format"...
    To
    "URI to a X509 certificate (or certificate chain) signed by the IdentityCA, either as the root CA or as an intermediate CA, in PEM format"

    (2) In section 9.3.1.3 change from:
    "An X.509 v3 Certificate [39] that chains up to the Identity CA (see 9.3.1.1)."
    To:
    "A X.509 v3 Certificate chain [39] that is signed by the Identity CA (see 9.3.1.1) either as the root or as an intermediate CA in the chain"

    (3) In section 9.3
    In bullet 3. Clarify it may not be a single X.509 rather it can be a chain.

    (4) In table 49, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

    (5) In table 50, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

    (5) In table 52, field "validate_local_identity" indicate this is not a single certificate but a certificate chain.

    (6) In Table 53 IdentityCertificate is undefined. Maybe it should be "identity_certificate" and refer to the property defined in Table 44.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 9 Apr 2018 23:56 GMT
  • Updated: Mon, 9 Apr 2018 23:56 GMT

Reduce the range of Reserved RTPS parameter IDs

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

    Section 7.4.1.3 'Reserved RTPS parameter IDs' reserves the whole 0x1000 to 0x1FFF (plus 0x5000 to 0x5FFF for must-understand) . That is 2 x 16M PIDs. In reality DDS security only uses 6 PIDs... So this is a bit too much of a land grab.

    It would be better to be more conservative and reserve a smaller range which can then be expanded as needed.

    RTPS version 2.4 states that the reserved range for DDS security is 0x1000 to 0x10FF and 0x5000 to 0x50FF.

    Section 7.4.1.3 should be updated to reflect this reduced range.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Mar 2018 23:34 GMT
  • Updated: Mon, 9 Apr 2018 17:36 GMT

Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED

  • Status: open  
  • Source: OCI ( Tim Simpson)
  • Summary:

    All the other flag names defined here take the form of "PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_XXX_YYY". Should the BUILTIN part of this flag really be there? I believe this should instead read: PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_DISCOVERY_ENCRYPTED.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 22:02 GMT
  • Updated: Fri, 6 Apr 2018 19:23 GMT

Broken cross-references

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

    There are a few cross-references that don't resolve, resulting in the text "see 0" or "in subclause 0" in the spec:

    • Table 30 plugin_endpoint_attributes column 3 contains "found in 0"
    • Table 52 get_authenticated_peer_credential_token contains "See section 0"
    • 9.4.1.2.6.7 right before the bullet list
    • Table 63 validate_remote_permissions
    • 9.5.3.3.4.1 final paragraph has "subclause 0"
  • Reported: DDS-SECURITY 1.1b1 — Wed, 21 Feb 2018 16:11 GMT
  • Updated: Thu, 15 Mar 2018 17:39 GMT

Replace "CryptoKeyTransform" with "CryptoTransform"

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

    The term CryptoKeyTransform is used 3 times (section name of 9.5.3.3, text of 9.5.3.3.1, caption of Table 72). These should be CryptoTransform.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 21:19 GMT
  • Updated: Fri, 9 Mar 2018 21:19 GMT

register_local_datareader and Data Protection Kind

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

    In the Table 70 row for register_local_datareader, the ReaderKeyMaterial is created based on Data Protection Kind. This should be Metadata Protection Kind because the ReaderKeyMaterial signs/encrypts submessages and not data payloads.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 20:51 GMT
  • Updated: Fri, 9 Mar 2018 20:51 GMT

IDL ParticipantSecurityAttributes::plugin_participant_attributes

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

    In the normative IDL, the struct ParticipantSecurityAttributes's field plugin_participant_attributes has type ParticipantSecurityAttributesMask but it should have type PluginParticipantSecurityAttributesMask

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 21:33 GMT
  • Updated: Thu, 8 Mar 2018 21:33 GMT

Return types in CryptoKeyFactory interface description

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

    In CryptoKeyFactory, all operations other than the unregister_* ones return handles. But the descriptions of register_matched_remote_participant and register_local_datawriter (8.5.1.7.2-3) end with "operation returns false". That should be "operation returns HandleNIL".

  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:31 GMT
  • Updated: Thu, 1 Mar 2018 19:31 GMT

AuthRequestMessageToken future_challenge property

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

    In Table 48 (9.3.2.4), "properties" should be "binary_properties" so that the property future_challenge is treated as binary, matching Table 49's challenge1.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:02 GMT
  • Updated: Thu, 1 Mar 2018 19:02 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: Wed, 28 Feb 2018 22:43 GMT

Modify Security's QoS changes for compatibility with RTPS

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

    Section 7.2.5 changes QoS in ways that break RTPS compatibility, however minor modifications can fix this.

    Because the mapping for PropertyQosPolicy in Table 10 (is this an implied entry in Table 12 as well?) conflicts with RTPS's definition of PID 0x59, the Binary Property values may not be sent on the wire. Note that RTPS has no concept of appendable extensibility, and requires backwards compatibility for all 2.x versions.

    We can represent this restriction on PropertyQosPolicy in IDL4:

    @extensibility(FINAL)
    struct PropertyQosPolicy {
      PropertySeq value;
    
      @non-serialized
      BinaryPropertySeq binary_value;
    };
    

    The practical effect of this change is that any BinaryProperty entry with propagate == TRUE is not actually propagated inside PropertyQosPolicy. However a search through the specification indicates that there is no requirement for this, at least for built-in plugins. Any other plugins are necessarily vendor specific so those are not necessarily restricted from using an appendable policy, as long as they are aware of the compatibility issues (for allow_unauthenticated_participants == TRUE).

    Also, for consistency the Tag and DataTags structs could be made @extensibility(FINAL). This is not as important since only Security-aware implementations will know about DataTagQosPolicy.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 19 Feb 2018 23:37 GMT
  • Updated: Mon, 19 Feb 2018 23:39 GMT

Description of the EndpointSecurityAttributes

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

    In Table 30, the entry for is_payload_protected says "If is_payload_protected is FALSE, then the CryptoKeyFactory, KeyExchange and CryptoTransform operations are called only if is_payload_protected is TRUE", but the last phrase should be "only if is_submessage_protected is TRUE".

  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:16 GMT
  • Updated: Fri, 16 Feb 2018 23:16 GMT

Description of the PluginEndpointSecurityAttributes

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

    The rows in Table 61 is_submessage_encrypted and is_payload_encrypted each have paragraphs starting "If is_*_encrypted is FALSE..." and including "GCM authenticated encryption", which should be "GMAC authentication transformation" like the corresponding rows of Table 59.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:06 GMT
  • Updated: Fri, 16 Feb 2018 23:06 GMT

Wrong XML tag in description of Enable Read Access Control

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

    9.4.1.2.6.4 describes Enable Read Access Control, however the bullet list within this section uses the xml tag <enable_write_access_control> (twice), it should be <enable_read_access_control>.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 22:33 GMT
  • Updated: Fri, 16 Feb 2018 22:33 GMT

Use a submessage flag to indicate Data/Frag submessage has a transformed payload

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

    If the crypto plugin transforms the payload but the layers containing the payload (submessage or message) are not transformed, the resulting Data/Frag submessage contains no indication that its payload has a nonstandard format.
    Since this spec is essentially defining a new minor version of RTPS (along with RTPS RTF process concurrent to this), one of the reserved flags in the submessage header of Data/Frag can be defined as FLAG_S meaning that the format of the SerializedPayload submessage element is defined by the security spec.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 15 Feb 2018 19:38 GMT
  • Updated: Thu, 15 Feb 2018 19:42 GMT

Security for DDS-RPC

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

    DDS security does not provide any additional means to secure the DDS-RPC service calls. Absent this the protection would be based on the underlying DDS Topics.

    DDS-RPC maps all operations of an interface to two unkeyed Topics. One for the request and one for the reply. The request Topic is used for all operations and likewise the reply Topic.

    Thus relying on the underlying Topics would provide access control granularity at the level of the service and not allow to give narrower permissions. E.g. invoke certain operations and not others. This is not acceptable in some deployment situations.

    One solution may be to make the Topics keyed by the operation. This is possible now that IDL42 allows the discriminator of a union to act as the key.

    Alternatively DDS-Security could specify some other mechanism, for example designate a data-tag to indicate the operations that the request DataWriter may invoke. The receiver side would check that the operation invoked matches the DataWriter tag before processing the request.

  • Reported: DDS-SECURITY 1.1b1 — Sun, 11 Feb 2018 07:43 GMT
  • Updated: Sun, 11 Feb 2018 07:43 GMT

IDL get_topic_sec_attributes parameter typo

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

    2nd parameter to get_topic_sec_attributes has type "String", should be "string".

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:07 GMT
  • Updated: Fri, 9 Feb 2018 22:15 GMT

Specify DDS Security uses XCDR serialization version 1

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

    Starting with DDS-XTYPES version 1.2 a data type can be serialized using XCDR version 1 or version 2. This impacts the serialization of APPENDABLE and MUTABLE types. It does not impact the serialization of FINAL types unless they contain 8-byte primitives (long long or double).

    DDS-Security was written before DDS-XTYPES 1.2 came out. So all the products are using XCDR version 1.

    Going forward DDS-Security should specify that it always uses XCDR version 1 for serialization of the types defined in the specification.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Feb 2018 22:21 GMT
  • Updated: Thu, 8 Feb 2018 22:21 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: Fri, 2 Feb 2018 16:31 GMT

Determining when to use DCPSParticipantMessageSecure

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

    The last paragraph of 7.4.2 indicates that TopicSecurityAttributes::is_liveliness_protected is used to determine if a liveliness message should be sent using the new DCPSParticipantMessageSecure builtin endpoint or the old DCPSParticipantMessage builtin endpoint.

    However it is not clear which topic's TopicSecurityAttributes are to be used. The liveliness message essentially belongs to the participant and not any given topic (see RTPS v2.2 8.4.13.5). Should the security spec use ParticipantSecurityAttributes here instead?

  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Feb 2018 17:03 GMT
  • Updated: Thu, 1 Feb 2018 17:03 GMT

ParticipantStatelessMessage definition

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

    Section 7.4.3.2:

    The data type associated with these endpoints is ParticipantStatelessMessage defined
    below (see also 7.2.5):
    typedef ParticipantStatelessMessage ParticipantGenericMessage;

    Two issues:
    a. I don't see how this relates to 7.2.5, should that be 7.2.6?
    b. The typedef is backwards. Typedef declares a new name (second) from an existing type (first).

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:23 GMT
  • Updated: Tue, 30 Jan 2018 19:23 GMT

IDL SubscriptionBuiltinTopicDataSecure inheritance

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

    SubscriptionBuiltinTopicDataSecure should inherit from SubscriptionBuiltinTopicData in the local module, not the one in the DDS:: module.

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

IDL LongLongSeq unused

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

    DDS::Security::LongLongSeq is not used so it should be removed from the normative IDL.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:06 GMT
  • Updated: Tue, 30 Jan 2018 19:06 GMT

Authentication interface set_permissions_credential_and_token

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

    In the normative IDL, the type of the 2nd parameter for set_permissions_credential_and_token is listed as PermissionsCredential but should PermissionsCredentialToken.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:04 GMT
  • Updated: Tue, 30 Jan 2018 19:04 GMT

get_datawriter/reader_sec_attributes inconsistent IDL

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

    Table 32 (8.4.2.9) has a topic_name parameter for both get_datawriter_sec_attributes and get_datareader_sec_attributes, however this parameter is not present in the normative IDL.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:59 GMT
  • Updated: Tue, 30 Jan 2018 18:59 GMT

decode_datawriter_submessage uses "in" for SecurityException

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

    In the normative IDL interface CryptoTransform, the decode_datawriter_submessage operation uses the "in" parameter passing mode for SecurityException – should be "out" or "inout".

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:54 GMT
  • Updated: Tue, 30 Jan 2018 18:54 GMT

SecureSubmessageCategory_t in normative IDL

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

    The normative IDL doesn't have SecureSubmessageCategory_t, but it does have SecureSumessageCategory_t which appears to be a typo.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:51 GMT
  • Updated: Tue, 30 Jan 2018 18:51 GMT

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

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 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

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

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

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

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

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:

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:

Complexity of Authentication Plugin Model

  • Key: DDSSEC12-1
  • Legacy Issue Number: 19793
  • Status: open  
  • Source: ADLINK Technology Ltd ( 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