DDS Security Avatar
  1. OMG Specification

DDS Security — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSSEC12-121 Problematic use of multiple INFO_SRC within an RTPS DDS-SECURITY 1.1b1 open
DDSSEC12-114 Provide a way for multiple vendors to extend the algorithms and interoperate DDS-SECURITY 1.1b1 open
DDSSEC12-102 Provide efficient way to skip encrypted implementation-specific content DDS-SECURITY 1.1b1 open
DDSSEC12-82 encode_rtps_message/decode_rtps_message error and status reporting DDS-SECURITY 1.1 open
DDSSEC12-99 Update parameters of check_remote_datawriter_register_instance DDS-SECURITY 1.1 open
DDSSEC12-89 Add return_permissions_handle to the AccessControl interface DDS-SECURITY 1.1 open
DDSSEC12-93 Add best practice/implementation guidelines to the CryptoTransform plugin DDS-SECURITY 1.1b1 open
DDSSEC12-88 Size of permission file sent on authentication can exceed max IP packet size DDS-SECURITY 1.1b1 open
DDSSEC12-74 Builtin Access Control operations (Table 63) missing entries DDS-SECURITY 1.1 open
DDSSEC12-84 The Qos used to publish the BuiltinLoggingTopic is not specicified DDS-SECURITY 1.1b1 open
DDSSEC12-83 class_id string in Authentication/Permissions Tokens should include spec version DDS-SECURITY 1.1b1 open
DDSSEC12-81 Authentication Protocol: Make what is validated in the messages more explicit DDS-SECURITY 1.1b1 open
DDSSEC12-70 Protecting the Source Timestamp DDS-SECURITY 1.1b1 open
DDSSEC12-80 Add support for ChaCha20 DDS-SECURITY 1.1b1 open
DDSSEC12-77 Invalid IETF RFC document reference. DDS-SECURITY 1.1b1 open
DDSSEC12-76 IDL should be updated to match IDL 4.2 DDS-SECURITY 1.1b1 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-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

Issues Descriptions

Problematic use of multiple INFO_SRC within an RTPS

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The RTPS spec allows a single RTPS message to contain multiple INFO_SRC submessages, effectively changing the Participant GUID of the sending Participant.

    This seems problematic for DDS Security since the cryptograophic material is tied to that Participant GUID (e.g. the RTPS protection).
    Also INFO_SRC does not work well with the new RTPS_HEADER_EXTENSION.

    How commonly is this capability used? It is worth finding a way to make DDS-Security work with it or would it be better to disallow it.

    Should it be disallowed just for DDS-Security or for DDS in general?

  • Reported: DDS-SECURITY 1.1b1 — Wed, 27 Sep 2023 13:24 GMT
  • Updated: Wed, 25 Oct 2023 04:44 GMT

Provide a way for multiple vendors to extend the algorithms and interoperate

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification provides mechanisms to extend the set of cryptographic algorithms in future revisions.
    The specification also provides mechanisms to extend the set of cryptographic algorithms by a single vendor without requiring a revision of the standard. Those extended algorithms will be understood by the vendor and ignored by others.
    What is not clear is if two vendors can agree to use another cryptographic algorithm and interoperate. This use-case may be relevant to an end-user that is using multiple vendors and wants to have those vendors work together to use a new crypto algorithm

    This issue requests some mechanism to support this last use case.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 30 Jun 2023 16:34 GMT
  • Updated: Mon, 3 Jul 2023 17:18 GMT

Provide efficient way to skip encrypted implementation-specific content

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The RTPS specification allows implementations to send implementation-specific RTPS sub-messages inside an RTPS message. These submessages are distinguished by having submessageId's within a specific range.

    Prior to DDS security skipping implementation-specific RTPS sub-messages was very efficient requiring only the receiver to jump their length indicated in. the header.
    However with DDS security the submessages can be encrypted inside a SRTPS_PREFIX/SUFFIX envelope this requires the receiver to always decrypt them even if it will end up skipping them.
    An extreme, but likely common case is when the SRTPS_PREFIX/SUFFIX contains exclusively implementation-specific RTPS sub-messages which makes the effort to decrypt the RTPS message fruitless.

    A way to resolve this would be to designate a flag in the SRTPA_PREFIX submessage to indicate that the content contains only vendor-specific submessages. A receiver can use this flag to skip the whole RTPS message avoiding the effort to decrypt i n the event that the sender vendorId does not match the receiver's.

    The proposal therefore is to designate the leftmost flag of the SRTPS_PREFIX submessage to indicate it contains only "vendor specific content".

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Jun 2023 04:35 GMT
  • Updated: Thu, 8 Jun 2023 13:21 GMT

encode_rtps_message/decode_rtps_message error and status reporting

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    8.5.1.9.4 (4th pgh) describes that encode_rtps_message may determine that no encoding is necessary. This is currently an awkward fit with the common API design of returning a boolean and "setting" or "not setting" an exception struct. What does "not setting" the exception struct mean in practice? How does an implementation portably handle this?

    It would be better to have an enum or integer return type so that the plugin can more directly influence the implementation's control flow, with distinct return values for OK_ENCODED, OK_NOT_ENCODED, ERROR, possibly others.

    A similar issue occurs with decode_rtps_message (8.5.1.9.5). Because key exchange happens asynchronously with respect to encoded message transmission, the plugin may not be able to decode a given message. Simply "returning an exception" in this case is not ideal since the calling code should probably log this exception and it may raise alarms.

    Extending this idea of enum (or integer constants) return types instead of boolean to other CryptoTransform operations may also be useful. For example, the other encode operations could return a OK_NOT_ENCODED instead of copying data.

  • Reported: DDS-SECURITY 1.1 — Tue, 17 Sep 2019 21:53 GMT
  • Updated: Tue, 13 Dec 2022 22:35 GMT

Update parameters of check_remote_datawriter_register_instance

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    check_remote_datawriter_register_instance defined in 8.4.2.9.15 has these parameters: permissions_handle, reader, publication_handle, key, exception.

    In the IDL file and Table 32 in 8.4.2.9 there's also an instance_handle parameter, which should be removed.

  • Reported: DDS-SECURITY 1.1 — Fri, 24 Jun 2022 19:50 GMT
  • Updated: Fri, 24 Jun 2022 19:50 GMT

Add return_permissions_handle to the AccessControl interface

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Handles that are allocated by plugins need to have a "return" operation so that the memory used by the plugin can be freed when the handle is no longer needed by the middleware.

    boolean return_permissions_handle(in PermissionsHandle handle,
      inout SecurityException ex);
    
  • Reported: DDS-SECURITY 1.1 — Thu, 1 Oct 2020 16:12 GMT
  • Updated: Fri, 12 Nov 2021 17:50 GMT

Add best practice/implementation guidelines to the CryptoTransform plugin


Size of permission file sent on authentication can exceed max IP packet size

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Permission File is an XML file. The signature is also encoded as text. For large systems with a lot of Topics the size can grow to be quite big. This is amplified by the fact that it is possible and convenient to combine the permissions of multiple participants into a single file. This size can exceed the 64KB max size of IP.

    An additional problem is that the permissions file is sent during the authentication handshake. The authentication handshake uses a special "best efforts stateless" that does not support fragmentation of large packets. This is done on purpose to make the channel to be robust to sequence number attacks but it results on the inability to send these large permission files.

    This could be addressed by separating the permissions from the authentication handshake and there is already an issue filed for this, see DDSSEC12-13.

    However there is a simple solution that can make the current approach more scalable. The proposed approach is to send the Permissions document compressed rather than in their current text form.

    Users are already hitting this limit so this issue requests that capability to send the permissions compressed is added with high priority, even if later a more general solution is developed as requested in DDSSEC12-13.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 1 Sep 2020 17:50 GMT
  • Updated: Sun, 13 Sep 2020 19:22 GMT

Builtin Access Control operations (Table 63) missing entries

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The operations get_topic_sec_attributes, 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: Sun, 21 Jun 2020 22:40 GMT

The Qos used to publish the BuiltinLoggingTopic is not specicified

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 9.6 'Builtin Logging Plugin' should specify the Qos used to publish and subscribe to the BuiltinLoggingTopic, similar to how it is done for other builtin topics introduced by DDS-Security.

    See for example how it is done for the DCPSParticipantMessageSecure builtin Topic (section 7.4.2) where it refers to the Qos of other builtin Topics and also how it is done for the TopicBuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader (section 7.4.4.2 ) where it defines it explicitly.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 26 Mar 2020 16:48 GMT
  • Updated: Thu, 26 Mar 2020 16:48 GMT

class_id string in Authentication/Permissions Tokens should include spec version

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The class_id attribute in various Tokens includes the Plugin Name and a version number. The intention was that the version number would track the specification version so that it could be used to understand the format of the Token.

    However this is not done consistently. Currently the following class_id are used:

    token class_id
    IdentityToken "DDS:Auth:PKI-DH:1.0"
    AuthenticatedPeerCredentialToken "DDS:Auth:PKI-DH:1.0"
    AuthRequestMessageToken "DDS:Auth:PKI-DH:1.0+AuthReq"
    HandshakeRequestMessageToken "DDS:Auth:PKI-DH:1.0+Req"
    HandshakeReplyMessageToken "DDS:Auth:PKI-DH:1.0+Reply"
    HandshakeFinalMessageToken "DDS:Auth:PKI-DH:1.0+Final”
    PermissionsToken "DDS:Access:Permissions:1.0"
    PermissionsCredentialToken "DDS:Access:PermissionsCredential"
    CryptoToken "DDS:Crypto:AES_GCM_GMAC"

    As it can be seen some class_ids are missing the version number. The ones that have it use "1.0" instead of "1.1" which is the version of the spec. Finally when there are multiple tokens with the same class ID a suffix preceded by a "+" is uses to differentiate them, but this is not done in all cases.

    The goal of this issue is to correct this irregularities. So DDS Security version 1.2 should modify the Token as follows:

    token class_id
    IdentityToken "DDS:Auth:PKI-DH:1.2"
    AuthenticatedPeerCredentialToken "DDS:Auth:PKI-DH:1.2+AuthPeer"
    AuthRequestMessageToken "DDS:Auth:PKI-DH:1.2+AuthReq"
    HandshakeRequestMessageToken "DDS:Auth:PKI-DH:1.2+Req"
    HandshakeReplyMessageToken "DDS:Auth:PKI-DH:1.2+Reply"
    HandshakeFinalMessageToken "DDS:Auth:PKI-DH:1.2+Final”
    PermissionsToken "DDS:Access:Permissions:1.2"
    PermissionsCredentialToken "DDS:Access:Permissions:1.2+Cred"
    CryptoToken "DDS:Crypto:AES_GCM_GMAC:1.2"

    Note that this change is not intended to break backwards interoperability. So the proposal could/should be adjusted to ensure that. Specifically the change in the name for the PermissionsCredentialToken should not impact interoperability as this token is not exchanged between participants. The same is true for the addition of the "+AuthPeer" to the AuthenticatedPeerCredentialToken.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 17 Dec 2019 00:26 GMT
  • Updated: Tue, 17 Dec 2019 00:51 GMT

Authentication Protocol: Make what is validated in the messages more explicit

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Builtin Authentication Protocol described in 9.3.4.2 'Protocol description' as well as in Table 52 'Actions undertaken by the operations of the builtin Authentication plugin' should be more explicit about how each of the protocol messages is validated.

    Specifically it should prescribe that:

    • Participant_A shall check the fields inside HandshakeReplyMessageToken and ensure that {Challenge1, Hash(C1), DH1}

      match what Participant A sent in the HandshakeRequestMessageToken.

    • Participant_B shall check the fields inside HandshakeFinalMessageToken and ensure that {Hash(C1), Hash(C2), DH1, DH2, Challenge1, Challenge2}

      match what Participant B sent in the HandshakeRequestMessageToken.

    This should be made clear both in 9.3.4.2 'Protocol description' and in Table 52 'Actions undertaken by the operations of the builtin Authentication plugin'.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Aug 2019 17:13 GMT
  • Updated: Tue, 6 Aug 2019 17:13 GMT

Protecting the Source Timestamp

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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: Tue, 16 Jul 2019 17:28 GMT

Add support for ChaCha20

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

Invalid IETF RFC document reference.

  • Status: open  
  • Source: ZettaScale Technology ( Mr. 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

IDL should be updated to match IDL 4.2

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

Multiple grants in a permissions document

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. 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: Object Computing, Inc. - OCI ( Mr. 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: Object Computing, Inc. - OCI ( Mr. 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

Builtin Auth dependency on Access Control details

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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: Object Computing, Inc. - OCI ( Mr. 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: Object Computing, Inc. - OCI ( Mr. 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: Object Computing, Inc. - OCI ( Mr. 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: Object Computing, Inc. - OCI ( Mr. 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: Object Computing, Inc. - OCI ( Mr. 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