${taskforce.name} Avatar
  1. OMG Task Force

DDS Security 1.1 RTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSSEC11-82 OCSP stapling to enhance certificate status checking during handshake DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-19 Invalid domain_id tag used in multiple sections of the spec DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-112 No mechanism to free ParticipantSecurityAttributes or EndpointSecurityAttributes DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-38 Clarify whether governance settings for a DataWriter and a DataReader must be consistent for a match to occur DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-14 Clarify conditions for calling the operations on AccessControlPlugin DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-118 begin_handshake_request in the IDL Not Consistent with the Main Document DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-115 Add the concept of "data origin authentication" and clarify what DDS-Security provides DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-111 Unclear Effectiveness of is_rtps_protected=true allow_unauthenticated_participants=true DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-52 Specify Authentication Challenge Length DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-58 Clarify the receiver-specific MACs described in the Table 57 decode operations DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-137 Missing Mechanism for Detecting Incompatibilities in ParticipantSecurityAttributes DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-39 Use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-23 FIPS-196 reference to wrong chapter DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-48 Wrong Facility Value for Logging Plugin DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-47 Need to specify format of SubjectName used for adjusted_participant_key DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-106 Should differences in EndpointSecurityAttributesMask prevent matching? DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-96 dds_security_plugins_spis.idl has inheritance commented out DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-49 Apply sha256 to derived shared secret DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-41 Correct Figure 9 to match description of the authentication protocol DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-40 Remove duplicate of RTPS message inside the security envelope DDS-SECURITY 1.0 DDS-SECURITY 1.1 Closed; No Change closed
DDSSEC11-25 VALIDATION_PENDING_CHALLENGE_MESSAGE DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-21 Normative IDL does not match the documentation for Auth::validate_remote_identity DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-22 Normative IDL does not match documentation for Authentication::validate_remote_identity DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-27 Inconsistent Behavior for Secure Volatile Endpoints DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-110 Handling expiration of Permissions or Certificates during operation DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-81 Non-Recoverable Communication After Authentication Session Terminated DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-85 Additional typos/inconsistencies DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-70 Unnecessary Additional Authenticated Data in common_mac DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-66 Handling large numbers of receiver-specific MACs DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-62 Inconsistent format for Starting and End Dates in Validity Section DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-53 Specify a transformation_kind for BuiltinParticipantVolatileMessageSecure Endpoints DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-60 Wrong description of max_blocks_per_session DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-34 check_local_*_match publisher/subscriber partition not present in IDL DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-16 AccessControl behavior does not show check_local_datawriter/reader_match operations DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-17 Need a way to determine the builtinTopic used for the DataWriter automatic liveliness DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-123 Inconsistent IDL encode_serialized_data and decode_serialized_data DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-122 Spec does not explain how t would use different keys for the encode_serialized_payload versus encode_serialized_submessage DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-88 BuiltinTopicKey_t Inconsistent with current DDS Spec DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-44 Denial of Service Attack to DDS Security Participants by Injecting Participant Discovery Unregister&Dispose DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-43 Non Recoverable Communication After Asymmetric Liveliness Loss DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-36 get_endpoint_sec_attributes inconsistently specified DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-33 AccessControl::check_create_topic( str_properties ) only present in IDL DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-12 GUIDs for new builtin Topics do not comply with DDS-RTPS specification DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-31 Wrong ValidationResult_t VALIDATION_OK_WITH_FINAL_MESSAGE Used In Multiple Places DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-29 Inconsistent Definition of BuiltinLoggingType DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-15 SecurityExceptionCode is undefined DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-108 Participant's is_access_protected Functionality Overlaps with allow_unauthenticated_participants DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-72 EndpointSecurity's is_payload_protected is Insufficient DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-55 Confusing Sentence about Builtin Endpoints Payload Encryption DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-56 Permissions grant rule with no specified topic DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-46 Missing a Way to Pass Participant Data to begin_handshake_request and begin_handshake_reply DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-35 get_*_token should not return non-boolean values DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-24 Inconsisten ReturnCode NOT_ALLOWED_BY_SEC DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-18 Issue on DDS Security metamodel DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-6 Permissions XSD and XML files are inconsistent with normative machine readable file DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-94 Unify treatment of builtin endpoints with that of regular endpoints DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-54 Specify Endianness to be Used in Ciphertext DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-57 Evaluation of data_tags when checking Permissions is unclear DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-45 discovery_protection_kind is Underspecified DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-42 Table 51 CryptoToken should specify endianness of binary properties DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-7 Inconsistency in SubMessage and SubMessageElement naming throughout document DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-8 Crypto factory plugin implementation key generation DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-4 Name of builtin topic is DCPSParticipantMessage not ParticipantMessage DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-3 How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign? DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-2 DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Closed; No Change closed
DDSSEC11-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-5 Miscellaneous typos/inconsistencies DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-113 Examples of Wildcard permissions DDS-SECURITY 1.0 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-11 How is single-MAC versus MAC-per-reader configured? DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-10 Provide mechanisms to extend Governance and Permissions files without breaking interoperability DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-9 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-93 Determining the wire version of the DDS Security Protocol DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed

Issues Descriptions

OCSP stapling to enhance certificate status checking during handshake

  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    Similarly to TLS OCSP stapling (RFC 6066, §8, improved by RFC 6961), OCSP stapling consists to send the certificate status (OCSP response) in the handshake message, saving roundtrips and resources. This would enhance handshake performance and energy saving in DDS security

    This requires to add a new (optional) binary property like c.status to HandshakeRequestMessageToken and HandshakeReplyMessageToken and value is a DER-encoded OCSP response (using the ASN.1 type OCSPResponse defined in RFC2560) that provides the status of the certificate in c.id property. Then begin_handshake_reply() and process_handshake() should honor this property if present.

    This issues has been merged with DDSSEC11-110. So the resolution to this issue should also address the certificate expiration issue raised in DDSSEC11-100.

  • Reported: DDS-SECURITY 1.0 — Mon, 22 May 2017 06:40 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add support for OCSP stapling

    The issue is addressed by adding two features:
    (1) The DomainParticipant will be able to attach (staple) the OCSP response during the Authentication Protocol, as an extra field in the Tokens that are exchanged. This ca be used to ensure freshness at the time the authentication occurs.

    (2) The DomainParticipant will be able to include the OCSP response in its ParticipantBultinTopicDataSecure. This would help ensure freshness after authentication completed.

    Details of the configuration for the freshness limits and handling of expired certificates are left to the implementors.

  • Updated: Thu, 11 Mar 2021 20:10 GMT

Invalid domain_id tag used in multiple sections of the spec

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

    The following sections are incorrectly using the "domain_id" instead of "domains":

    • 9.4.1.2.4.1 Domains element: "This element is delimited by the XML element <domain_id>."
    • 9.4.1.2.7 Example Domain Governance document (non normative)
      ... "<domain_id>0</domain_id>" ...
    • 9.4.1.3.2.3.1.1 Domains Section: "This Section is delimited by the XML element <domain_id>."
  • Reported: DDS-SECURITY 1.0 — Fri, 2 Sep 2016 14:38 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Correct XML tag <domain_id>. Should be <domains> *

    Replace <domain_id> with <domains> in 9.4.1.2.4.1, 9.4.1.2.7, and 9.4.1.3.2.3.1.1

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

No mechanism to free ParticipantSecurityAttributes or EndpointSecurityAttributes

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

    get_participant_sec_attributes, get_datawriter_sec_attributes, and get_datareader_sec_attributes return ParticipantSecurityAttributes and EndpointSecurityAttributes.

    These attributes contain PropertySeq, which needs to be allocated. So the Access Control plugin is responsible for allocating the SecurityAttributes, but there's no mechanism to deallocate them.

    The DDS core could possibly deallocate them, but for consistency, the Access Control plugin should do that job.

    There should be functions return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes that take the attributes and return boolean.

  • Reported: DDS-SECURITY 1.0 — Mon, 10 Jul 2017 13:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes

    This proposal will add return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes.

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

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

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

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

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

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

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

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

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

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

    Define PID for Sending Endpoint Security Attributes

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

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

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

Clarify conditions for calling the operations on AccessControlPlugin

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

    Table 21 (Description of the ParticipantSecurityAttributes) entry on "ParticipantSecurityAttributes :is_access_protected" mentions allowing matching of participants without having "authorization" from the AccessControl. This is underspecified. It should state what this means in terms of the access control plugin operations are called (or not called) and how their return values are handled.

    Specifically. Is register_matched_remote_participant still called? Is validate_remote_permissions still called?

    Conceptually saying ParticipantSecurityAttributes::is_access_protected=FALSE only means we allow open access to the DomainId, but that does not imply open access to all the Topics...

    This fact is implied by the rules in 8.8.7 (AccessControl behavior with remote domain entity discovery) which permit "Unauthenticated" participants to only join domains that have ParticipantSecurityAttributes::is_access_protected=FALSE but only read/write the topics with EndpointSecurityAttributes::is_access_protected==FALSE.

  • Reported: DDS-SECURITY 1.0 — Tue, 24 May 2016 01:11 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes to Clarify the Behavior of the AccessControl Plugin with Different Participant Security Attributes

    This will clarify how the Participant and Endpoint Security interact with the plugins behavior.

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

begin_handshake_request in the IDL Not Consistent with the Main Document

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

    In the DDS Security, Table 18 – Authentication plugin interface, begin_handshake_request is defined as:

    (empty) ValidationResult_t
    out: handshake_handle HandshakeHandle
    out: handshake_message HandshakeMessageToken
    initiator_identity_handle IdentityHandle
    replier_identity_handle IdentityHandle
    serialized_local_participant_data octet[]
    exception SecurityException

    However, in the normative IDL, is defined as:

                ValidationResult_t
                    begin_handshake_request(
                        inout HandshakeHandle        handshake_handle,
                        in    HandshakeMessageToken  handshake_message_out,
                        in    HandshakeMessageToken  handshake_message_in,
                        in    IdentityHandle         initiator_identity_handle,
                        in    IdentityHandle         replier_identity_handle,
                        in    OctetSeq               serialized_local_participant_data,
                        inout SecurityException      ex );
    

    This is, the IDL has two issues:

    • "in HandshakeMessageToken handshake_message_in" should be removed
    • "in HandshakeMessageToken handshake_message_out" should be marked as inout and renamed "handshake_message"
  • Reported: DDS-SECURITY 1.0 — Thu, 13 Jul 2017 13:02 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix Inconsistent begin_handshake_request in the IDL

    This will cover changes in IDL to be consistent with the document.

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

Add the concept of "data origin authentication" and clarify what DDS-Security provides

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

    Section 4 of the spec (Terms and Definitions) should be expanded to include these additional definitions.

    Data Integrity
    Assurance that data has not been altered since creation time.

    Data Origin Authentication
    A mechanism providing assurance that a party is corroborated as the source of specified data (it includes data integrity).

    Message Authentication
    An alternative term for Data Origin Authentication.

    Section 7.1 says that Securing DDS means providing "Non-repudiation of data" instead it should say "data-origin authentication"

  • Reported: DDS-SECURITY 1.0 — Wed, 12 Jul 2017 22:06 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Clarify Data Origin Authentication versus Non-Repudiation

    In Section 4 (Terms and Definitions) add definitions for: Data Integrity, Data Origin Authentication, and Message Origin Authentication.

    In Section 7.1 (Security Model) list also Message-origin and Data-origin authentication. Indicate that Non-repudiation may be optional.

    In Section 9.2 (Requirements and Priorities (Non-Normative)) change "Message integrity and authentication" to "Message integrity and data-origin authentication"

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

Unclear Effectiveness of is_rtps_protected=true allow_unauthenticated_participants=true

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

    Current specification allows for creating a participant with is_rtps_protected=true and allow_unauthenticated_participants=true.

    According to "Table 21 – Description of the ParticipantSecurityAttributes - is_rtps_protected":

    If is_rtps_protected is TRUE then:
    (1) The DDS middleware shall call the operations on the CryptoKeyFactory for the DomainParticipant.
    (2) The DDS middleware shall call the operations on the CryptoKeyExchange for matched DomainParticipants that have been authenticated.
    (3) The RTPS messages sent by the DomainParticipant to matched DomainParticipants that have been authenticated shall be transformed using the CryptoTransform operation encode_rtps_message and the messages received from the matched authenticated DomainParticipants shall be transformed using the CryptoTransform operation decode_rtps_message.

    In particular, I want to focus on (3). According to current specification, we should accept a not-signed RTPS message coming from an unauthenticated participant, independently of the "is_rtps_protected" value. I think this impacts the effectiveness of just using "is_rtps_protected". This is because it allows for an attacker to inject any RTPS message by properly tampering the GUID if that GUID has not been authenticated yet (at the very minimum, it enables for a time window that allows for injecting anything, until that GUID is actually authenticated).

    I want to bring this up so we can discuss if this is actually the behavior we want (if this is the case, we should document the scenario I described above somewhere), or if is_rtps_protected=true should be incompatible with allowing unauthenticated participants. If that is the case, the alternative secure configuration would be to protect submessages themselves (by signing them).

  • Reported: DDS-SECURITY 1.0 — Mon, 10 Jul 2017 13:41 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-14 and its resolution (DDSSEC11-126)

    Duplicates DDSSEC11-14 (and its already handled by its resolution DDSSEC11-126)

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

Specify Authentication Challenge Length

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

    Table 38 – HandshakeRequestMessageToken for the builtin Authentication plugin specifies the challenge as:

    A Random Challenge generated by the Participant,
    compliant with the recommendations of Section 3.2.1 of
    FIPS-196 [46]
    

    This is currently underspecified, as it does not impose restrictions to the challenge length. This can lead to vendor interoperability issues. In order to avoid these issues, the DDS-SECURITY specification should specify alength for DDS-SECURITY 1.0 interoperability. Proposal: 256 bits.

    NOTE: In https://tools.ietf.org/html/rfc5246 page 90 that for TLS 1.2, the challenge_length is between 16 and 32 bytes.

    Per the resolution of http://issues.omg.org/browse/DDSSEC_-114 it was established that challenges should contain 32 bytes of randomness so the proposal is to specify that the challenge shall be exactly 32 bytes.

  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:19 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Specify a Challenge Length and Fixing Typo

    Define changes according to DDSSEC11-52.

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

Clarify the receiver-specific MACs described in the Table 57 decode operations

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

    In Table 57, the language in decode_rtps_message and decode_datawriter_submessage should be made more consistent with the language in decode_datareader_submessage. For example, decode_datawriter_submessage mentions receiver_specific_mac_key_id and master_receiver_specific_mac_key, but those terms are not mentioned anywhere else in the specification.

    Proposal:

    decode_datareader_submessage: "receiver_specific key_id" is missing an underscore. It should be "receiver_specific_key_id".

    decode_datawriter_submessage: "receiver_specific_mac_key_id" and "receiver_mac_key_id" should be "receiver_specific_key_id". "master_receiver_specific_mac_key" should be "receiver_specific_macs".

    decode_rtps_message: "RemoteParticipant2ParticopantKeyMaterial" should be "RemoteParticipant2ParticipantKeyMaterial". "containe" should be "contained". Add "If the RemoteParticipant2ParticipantKeyMaterial specified a receiver_specific_key_id different from zero, then the operation shall check that the received SecureRTPSPostfixSubMsg contains a non-zero length receiver_specific_macs element containing the receiver_specific_key_id that is associated with local and remote CryptoHandles and use it to verify the submesage. If the receiver_specific_key_id is missing or the verification fails, the operation shall fail with an exception."

  • Reported: DDS-SECURITY 1.0 — Tue, 7 Mar 2017 14:25 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes to Table 57

    Perform the changes proposed in the issue description.

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

Missing Mechanism for Detecting Incompatibilities in ParticipantSecurityAttributes

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

    In DDSSEC11-38 (modified by DDSSEC11-72, and DDSSEC11-106) we introduced a mechanism for detecting inconsistencies in the EndpointSecurityAttributes.

    We are still missing an equivalent mechanism for detecting inconsistencies in the ParticipantSecurityAttributes.

  • Reported: DDS-SECURITY 1.0 — Mon, 31 Jul 2017 10:51 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define PID for Sending Participant Security Attributes

    This will define the a new PID for sending the local participant security attributes to the remote participant. This way, we enable for early detection of incompatibilities (such as encrypting discovery in one side, and just doing signing in the other).

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

Use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg

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

    The DDS Security FTF changed some aspects of the construction of submessages eliminating SecureSubMsg and the MultiSubmsg flag. However some of the old language was not removed from the specification. Because of these there a re some sections that need to be modified as they do not completely make sense the way they are written now.

    Note that SecureSubMsg and the use of the MultiSubmsg were eliminated by the FTF and they were replaced by the combination of newly created submessage: SecurePrefixSubMsg, SecurePostfixSubmsg, SecureRTPSPrefixSubmsg, SecureRTPSPostfixSubmsg and SecureBodySubMsg.

  • Reported: DDS-SECURITY 1.0 — Sun, 13 Nov 2016 17:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Correct use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg *

    Per the issue description, the following sections need to be corrected:

    Remove references to SecureSubMsg and replace with SecureBodySubMsg in:

    • Multiple places in: 7.3.6.2 RTPS Submessage: SecureSubMsg
    • 7.3.7.5.1 Wire Representation (the submessageId is wrong).
    • 8.5.1.9 : multiple places, see MultiSubmsg below
    • 8.8.10: multiple places, see MultiSubmsg below

    Remove references to MultiSubmsg and replace with the use of prefix/body/postfix pattern in:

    • 8.5.1.9.6 Operation: preprocess_secure_submsg: this needs to be modified to explain it now uses a prefix.
    • 8.5.1.9.7 Operation: decode_datawriter_submessage: this needs to be modified to explain that it now uses a SecurePrefixSubMsg.
    • 8.5.1.9.8 Operation: decode_datareader_submessage: this needs to be modified to explain that it now uses a SecurePrefixSubMsg.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

FIPS-196 reference to wrong chapter

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    Random Challenge recommendations are stated to be in non-existent Section 3.2.1 of FIPS-196.
    The correct Section is perhaps 3.1.2 (Random numbers).

  • Reported: DDS-SECURITY 1.0 — Mon, 3 Oct 2016 08:53 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Modify FIPS-196 reference to NIST Special Publication 800-90A

    Modify section 9.3.2.3 replacing the reference to a random number generation in FIPS-196 with a reference to the generation of a NONCE from NIST Special Publication 800-90A section 8.6.7

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

Wrong Facility Value for Logging Plugin

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

    According to the DDS Security specification (9.6 Builtin Logging Plugin), the facility value for the BuiltinLoggingType must be 0x10 (16 in decimal):

    octet facility; // Set to 0x10. Indicates sec/auth msgs
    LoggingLevel severity;
    

    However, according to the Syslog RFC 6.2.1. PRI (https://tools.ietf.org/html/rfc5424):

       Facility and Severity values are not normative but often used.  They
       are described in the following tables for purely informational
       purposes.  Facility values MUST be in the range of 0 to 23 inclusive.
    [...]
                 10             security/authorization messages
    [...]
                 16             local use 0  (local0)
    

    It defines 10 (0x0a) as the value for security/auth messages.

  • Reported: DDS-SECURITY 1.0 — Tue, 7 Feb 2017 00:58 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to correct logging facility

    Changes in Specification to correct logging facility as per DDSSEC11-48

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

Need to specify format of SubjectName used for adjusted_participant_key

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

    This is regarding the DDS Security spec Table 41 validate_local_identity “The 47 bits following the first bit (bits 1 to 47) shall be set to
    the 47 first bits of the SHA-256 hash of the SubjectName appearing on the identity_credential”.

    The format of the SubjectName is not specified. It should say “The 47 bits following the first bit (bits 1 to 47) shall be set to the 47 first bits of the SHA-256 hash of the ASN.1 DER encoding of the SubjectName [40] appearing on the identity_credential”, where [40] is https://tools.ietf.org/html/rfc5280, which is already in the References section.

    Section 4.1.2.6 and Appendix C.2 of the RFC are the most relevant sections.

  • Reported: DDS-SECURITY 1.0 — Wed, 7 Dec 2016 18:01 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Specify SubjectName Format

    This will define the changes to the specification according to DDSSEC11-47.

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

Should differences in EndpointSecurityAttributesMask prevent matching?

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

    http://issues.omg.org/browse/DDSSEC11-38 introduced an EndpointSecurityAttributesMask that is propagated by Discovery within the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData. This has the bit fields:

    is_access_protected	
    is_discovery_protected	
    is_submessage_protected	
    is_payload_protected	
    is_keyhash_obfuscated	
    is_liveliness_protected	
    

    So a participant only knows that a remote participant will "protect" the payload. But not the details of the protection. This is consistent with the fact that at the PIM level the DDS core only knows whether it needs to call the "encods_serialized_data" but not what this call does. It is the detail of a specific plugin (in our case the builtin ones) that has the knowledge of the SIGN versus ENCRYPT 'protection kinds'

    Currently the specification does not say whether matching should be allowed between endpoints that have different EndpointSecurityAttributesMask. This should be clarified.

    Moreover it seems it would not be possible with the current mechanisms to enforce that if a DataReader expects ENCRYPT, then it should get that rather than just SIGN. In principle this is something that could be enforced by the check_local_dataXXX_match operations. But it does not appear they get the information they need to make that determination.

  • Reported: DDS-SECURITY 1.0 — Wed, 5 Jul 2017 18:41 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define Mechanism for Matching Plugin Specific Attributes

    Define Mechanism for Matching Plugin Specific Attributes.

    Proposal: reserve a set of opaque bits on the endpoint security attributes mask to be used by security plugins.

    Also we are fixing in this issue an inconsistency between DDSSEC11-38 and DDSSEC11-72 (is_key_protected).

    NOTE: not adding information about origin_authentication as it should not prevent endpoint matching.
    Why is that? If the governance states that a Topic should have origin authentication I may be reasonable for a Reader to insist on that. Otherwise any data it accepts from that DataWriter would lack that and it would defeat the purpose of the configuration in the governance.
    I thought we wanted the writer to decide, but I see your point, I'm adding it

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

dds_security_plugins_spis.idl has inheritance commented out

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

    The inheritance relations for some of the structures dds_security_plugins_spis.idl appear in comments. See for example declaration of struct DomainParticipantQos:

            struct DomainParticipantQos { // : DomainParticipantQos {
                PropertyQosPolicy  property;
            }; //@Extensibility (MUTABLE_EXTENSIBILITY)
     

    In addition the syntax for the annotations is the legacy "comment-style" rather that the more modern "annotation style".

    To correct this the above declaration should be replaced with:

            @extensibility(MUTABLE)
            struct DomainParticipantQos : DDS::DomainParticipantQos {
                PropertyQosPolicy  property;
            }; 
     

    The same kind of changes should be applied to other declarations in the IDL.

  • Reported: DDS-SECURITY 1.0 — Thu, 1 Jun 2017 03:02 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Use explicit inheritance for BuitinTopics

    The issue is broader. The problem is that the syntax does not comply with IDL 4.1 or XTYPES 1.2.
    In addition to the use of IDL inheritance, the syntax of the IDL should be updated to:
    (1) Use the modern annotations @annotationName(anotationParam) rather than the syntax that places annotations in a comment
    (2) Use the IDL4.1/XTYPES 1.2 annotation names which are all lower case
    (3) Include http://www.omg.org/spec/DDS-XTypes/20170301/dds-xtypes_discovery.idl instead of dds_rtf2_dcps.idl this has more up-to-date definitions of the Qos and builtin topics.
    (4) Add definition of DomainId_t which is not in dds-xtypes_discovery.idl
    (5) Remove the keyword "local" ahead of interface declaration. In IDL41 "local" interfaces are in the CORBA building block.

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

Apply sha256 to derived shared secret

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

    Currently, section 9.3.2.3.2 says

    If the value of the c. kagree_algo property is “DH+MODP-2048-256”, then:
    • The Diffie-Hellman Public Key shall be for the 2048-bit MODP Group with 256-bit Prime Order Subgroup, see IETF RFC 5114 [47], section 2.3.
    • The Key Agreement Algorithm shall be the “dhEphem, C(2e, 0s, FFC DH) Scheme” defined in section 6.1.2.1 of NIST Special Publication 800-56A Revision 2 [48].
    Non-normative note: The OpenSSL 1.0.2 operation DH_get_2048_256() retrieves the parameters for the 2048-bit MODP Group with 256-bit Prime Order Subgroup.
    If the value of the c.kagree_algo property is “ECDH+prime256v1-CEUM”, then:
    • The Diffie-Hellman Public Key shall be for the NIST’s EC Curve P-256 as defined in appendix D of FIPS 186-4 [42] also known as prime256v1 in ANSI X9.62-2005 [41].
    • The Key Agreement Algorithm shall be the “(Cofactor) Ephemeral Unified Model, C(2e, 0s, ECC CDH)” defined in section 6.1.2.2 of NIST Special Publication 800-56A Revision 2 [48]. See also section 3.1 “Ephemeral Unified Model” of NIST Suite B Implementer’s Guide to NIST SP 800-56A [49].

    There's nothing wrong with this specification, but not all cryptography APIs provide a straightforward way of obtaining the raw bytes of a derived shared secret. Some APIs, such as the Microsoft Cryptography API: Next Generation (CNG), force you to compute a hash of the shared secret before obtaining the raw bytes of the hash. BCryptSecretAgreement outputs an opaque BCRYPT_SECRET_HANDLE, which you then pass into BCryptDeriveKey, which also takes a hash algorithm and outputs raw bytes. So in order to accommodate such APIs, the specification should state that a SHA-256 hash shall be applied to the derived shared secret.

  • Reported: DDS-SECURITY 1.0 — Wed, 22 Feb 2017 19:15 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to apply SHA256 to DH shared secret

    Specify changes to specification according to DDSSEC11-49

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

Correct Figure 9 to match description of the authentication protocol

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

    The description of the authentication protocol in 8.3.2.7 states that when a step in the authentication fails the plugin should revert back to the state it was before. This prevents a third party from interfering with the authentication and making it fail.

    However Figure 9 (Authentication plugin interaction state machine) does not show that. Instead it shows the state machine transitioning to the Final State. This should be corrected.

  • Reported: DDS-SECURITY 1.0 — Mon, 21 Nov 2016 16:44 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Update Figure 9 (Authentication plugin interaction state machine)

    Update Figure 9 to show that failure of any step does not exit the state machine. Rather the state reverts to the previous one. The state machine is exited only on a successful authentication or on a timeout.

    Add additional states to handle the VALIDATION_PENDING_RETRY return from the operations on the Authentication plugin.

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

Remove duplicate of RTPS message inside the security envelope

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

    Currently securing the RTPS message requires duplicating the RTPS header between the SecurePrefix and the SecureSuffix in order to be able to encrypt and sign.

    This may be useful when encryption is needed as it wold allow to put a "fake" RTPS header and obscure the content of the real one.

    However when we are signing only having the INFO_SOURCE seems an unnecessary duplication as it would be sufficient to include the existing RTPS in the computed MAC.

    To implement this it would be enough to add a flag to the SecurePrefix that indicates that the SecureSuffix MAC is done all the way from the beginning of the RTPS message (i.e. including the RTPS header).

    However this would break interoperability with any applications that do not understand this new flag...

    The only approach I can think of that does not break interoperability would be to add the flag to the SecureSuffix and include both signatures. One that does not include the RTPS header (for legacy applications) and one that does. The problem is that this would add the extra computation (and size) of the second signature which seems more expensive than just adding the INFO_SOURCE...

  • Reported: DDS-SECURITY 1.0 — Mon, 21 Nov 2016 16:29 GMT
  • Disposition: Closed; No Change — DDS-SECURITY 1.1
  • Disposition Summary:

    Not worth doing as it would break backwards interoperability

    The RTF task force decided it was not worth breaking backwards interoperability in order to gain what seems like fairly minimal performance.

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

VALIDATION_PENDING_CHALLENGE_MESSAGE

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    Table 41 suggests begin_handshake_request/reply returning VALIDATION_PENDING_CHALLENGE_MESSAGE, and states it shall be used to determine when to call process_handshake.
    This value is not part of the return type (ValidationResult_t).
    8.3.2.9.4 states that the operations use the other ValidationResults.

  • Reported: DDS-SECURITY 1.0 — Fri, 30 Sep 2016 08:34 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Correct VALIDATION_PENDING_CHALLENGE_MESSAGE

    See issue description.

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

Normative IDL does not match the documentation for Auth::validate_remote_identity

  • Status: closed  
  • Source: Kongsberg Geospatial ( Gilles Bessens)
  • Summary:

    In the normative IDL, validate_remote_identity's signature suggests it receives IdentityHandles for the initiator of and the replier to a handshake.
    This implies that this has been resolved by the middleware before calling Auth to initiate the sequence.
    In the specification document, however, the function instead receives IdentityHandles for the local and remote principal, moving the resolution to the plugin.
    The latter makes more sense, but to enforce this specification of the interface, the IDL has to be altered.

  • Reported: DDS-SECURITY 1.0 — Tue, 6 Sep 2016 10:28 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix validate_remote_identity on IDL and Document to be Consistent

    This will apply the changes described in DDSSEC11-21

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

Normative IDL does not match documentation for Authentication::validate_remote_identity

  • Status: closed  
  • Source: Kongsberg Geospatial ( Gilles Bessens)
  • Summary:

    In the normative IDL, validate_remote_identity's signature suggests it receives IdentityHandles for the initiator of and the replier to a handshake.
    This implies that this has been resolved by the middleware before calling Auth to initiate the sequence.
    In the specification document, however, the function instead receives IdentityHandles for the local and remote principal, moving the resolution to the plugin.
    The latter makes more sense, but to enforce this specification of the interface, the IDL has to be altered.

  • Reported: DDS-SECURITY 1.0 — Tue, 6 Sep 2016 10:14 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-21

    Duplicates DDSSEC11-21

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

Inconsistent Behavior for Secure Volatile Endpoints

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

    Secure Volatile Endpoint’s Endpoint Security Attributes are not defined by the spec. According to 9.5.2.1 DDS:Crypto:AES-GCM-GMAC CryptoToken, the encryption of the Secure Volatile Endpoint’s payload (the key material) is done by calling to encode_serialized_payload operation as part of “create_local_xxx_crypto_tokens(cryptoTokens /* out /)”. *This is inconsistent with the rest of endpoints, which will do encryption for the payload or submessages depending on the value of Endpoint Security Attributes.

    Additionally, current content is inconsistent with 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader, which details the key material needed for securing the channel. This is inconsistent, because current specification is not securing the channel, is just sending encrypted crypto tokens that have been encrypted in create_local_xxx_crypto_tokens, and decrypting them during the set_remote_xxx_crypto_tokens.

    Proposal (see DDSSEC11-28):
    • Change Secure Volatile endpoint definition to follow same encryption process than the rest of endpoints, being the only difference that the key material used is derived from the SharedSecret (as defined in 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader):
      • Secure Volatile endpoints will be consistent with the rest of endpoints.
      • Logic for create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens will be simplified.
    • Also protect the submessage metadata. Currently the specification only protects the CryptoToken this makes it vulnerable to someone attacking a participant by sending wrong hearbeats or NACKs on the Volatile Endpoint since the HB and NACKS are only protected if metadata is protected. For this reason Secure Volatile endpoint definition should specify metadata_protection_kind=ENCRYPT and data_protection_kind=NONE that way we protect both meta data and data with a single operation which is more efficient.
  • Reported: DDS-SECURITY 1.0 — Wed, 5 Oct 2016 11:10 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define Secure Volatile Endpoint Attributes and Simplify create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens

    General proposal:

    • Define Secure Volatile endpoint attributes to follow same encryption process than the rest of endpoints, being the only difference that the key material used is derived from the SharedSecret (as defined in 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader):
      • Secure Volatile endpoints will be consistent with the rest of endpoints.
      • Logic for create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens will be simplified.
    • Also protect the submessage metadata. Currently the specification only protects the CryptoToken this makes it vulnerable to someone attacking a participant by sending wrong hearbeats or NACKs on the Volatile Endpoint since the HB and NACKS are only protected if metadata is protected. For this reason Secure Volatile endpoint definition should specify metadata_protection_kind=ENCRYPT and data_protection_kind=NONE that way we protect both meta data and data with a single operation which is more efficient.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Handling expiration of Permissions or Certificates during operation

  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The Permissions document includes a validity range (not-before + not-after). Also, PKI certificates (used for identification) have an expiration date.

    The standard should address what happens when, during the course of operation, either of these expiration dates are passed. That is, 1) a peer is discovered and authenticated and permissions are validated; 2) time passes such that either or both (permission and/or certificate) expiration date/s pass/es.

    Two possible approaches:

    • Do nothing - that is, matched and validated entities continue to communicate uninterrupted.
    • Enforce expiration - The middleware periodically checks expiration dates and terminates communication when things expire.
    • There are probably other approaches.

    It is likely that the details are not important to interoperability, and can be left to the vendor.

  • Reported: DDS-SECURITY 1.0 — Sun, 9 Jul 2017 17:18 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Merge with DDSSEC11-82

    This issue is related to DDSSEC11-82 so it makes sense to handle both together

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

Non-Recoverable Communication After Authentication Session Terminated

  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    After two participants are mutually authenticated and authorized, each participant's session with the remote participant (certificate, shared secret, challenge1, challenge2...) may be terminated/removed at a certain time for various reasons such as:

    • Automatic termination: sessions should have a max lifetime to follow best security practices, to handle the fact that the remote participant's certificate may expire, be revoked, etc. and therefore no longer trusted (worst case scenario: the issuing CA (or any ancestor) cert expires/is revoked).
    • Administrative termination: some administrator decides to force the session termination because of a security alert or for debugging purposes.

    If the session is terminated on one side but not on the other, we end up in the same deadlock situation as in DDSSEC11-43 (scenario 1 and 2) except the root cause is not liveliness loss but simple automatic/administrative session termination.

  • Reported: DDS-SECURITY 1.0 — Sat, 20 May 2017 16:26 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Close as duplicate of DDSSEC11-43

    This will be handled with DDSSEC11-43

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

Additional typos/inconsistencies

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

    Several inconsistencies remain in the document:

    The document uses the terms " MasterReaderSpecificKey" and "MasterReceiverSpecificKey" to refer to the same key. Should rename one of the two. It would be better to keep MasterReceiverSpecificKey to be consistent with the name used for other keys, such as, SessionReceiverSpecificKey.


    Section 9.5.3.3.4.2 second paragraph starts: "Note that the built cipher operations..." The "built" word should be removed.


    The word: "operationg" is mis-spelled 5 times. Should be replaced with "operating"


    The words "AES-GMAC operation" appear 3 times in the spec. The more correct term would be "AES-GMAC transformation"


    Section 9.5.3.3.5 mentions a CryptographicSessionHandle three times. This is undefined. This really refers to the appropriate crypto handle (ParticipantCryptoHandle, DatawriterCryptoHandle, or DatawriterCryptoHandle).

    To fix this replace the first occurrence of "CryptographicSessionHandle" with "crypto handle (ParticipantCryptoHandle, DatawriterCryptoHandle, or DatawriterCryptoHandle)" and the remaining two occurences with "crypto handle"


    The IDL in the specification is still not using IDL 4.1 format. The following changes should be applied:
    @Extensibility (EXTENSIBLE_EXTENSIBILITY) -> @extensibility (APPENDABLE)
    @Extensibility (MUTABLE_EXTENSIBILITY) -> @extensibility (MUTABLE)


    Paragraph in section 9.4.1.2.4.6 (RTPS Protection Kind element) is in the wrong section
    The paragraph:

    This setting controls the contents of the ParticipantSecurityAttributes returned by the AccessControl::get_participant_sec_attributes operation on the DomainParticipant. Specifically the is_liveliness_protected attribute in the ParticipantSecurityAttributes shall be set to FALSE if and only if the value of the <liveliness_protection_kind> element is NONE.


    Appears in the wrong section. It should be moved to the end of 9.4.1.2.4.5 (Liveliness Protection Kind element)


    The numbered items in section 9.4.1.2.4 (Domain Rules) are missing one item. A new item numbered shown below should be inserted ahead of the current 6 (Topic Access Rules Section, containing topic rules).
    6. RTPS Protection Kind Element


    Provide the means to force strict parsing/formatting of the Governance file. See comments on DDSSEC11-114.

    The resolution of DDSSEC11-114 only addressed the strict formatting of the permissions file, not the governance file. To address the latter the AccessControl plugin should have an additional property "dds.sec.access.enable_strict_governance_formatting" with possible values "true" or "false". This property shuld be added ton 9.4.1(Configuration), Table 48 (Properties used to configure the builtin AccessControl plugin).

    The text in the newly added (by DDSSEC11-114) sections 9.4.1.2.5.9 Unknown elements in the domain rules and 9.4.1.2.5.9 Unknown elements in the topic rules would also need to change to say that this configured in the plugin, not controlled by the <enable_strict_permission_formatting>.element in the Governance file.

    In sections 9.4.1.2.5.9 (Unknown elements in the domain rules) and 9.4.1.2.6.8 (Unknown elements in the topic rules) the last paragraph in the section (see below) is wrong and should mention a configuration of the plugin instead:

    As specified in 9.4.1.2.5.7, unknown elements are only allowed if the governance file has set the Enable Strict Permissions Formatting element to FALSE.



    In 8.5.1.9.3 last paragraph, change receiving_datawriter_crypto_list.length with Length(receiving_datawriter_crypto_list)



    In section 7.4.1.5 after table 13 add IDL representation of the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData

            @extensibility(MUTABLE)
            struct PublicationBuiltinTopicDataSecure  :  DDS::PublicationBuiltinTopicData {
    	    @id(0x1003)  DataTags data_tags;
            };
    
            @extensibility(MUTABLE)
            struct SubscriptionBuiltinTopicDataSecure  :  DDS::SubscriptionBuiltinTopicData {
    	    @id(0x1003)  DataTags data_tags;
            };
    


    In many of the tables there are "out" parameters, such as the exception that are not marked as such. They should be corrected.



    DDSSEC11-17 added enable_liveliness_protection but the XSD was not updated accordingly. To correct, in
    in section 9.4.1.2.3 "Domain Governance document format" in the Governance XSD under, under<xs:complexType name="TopicRule">, change from:

                <xs:element name="enable_discovery_protection" type="xs:boolean" />
    

    To:

                <xs:element name="enable_discovery_protection" type="xs:boolean" />
                <xs:element name="enable_liveliness_protection" type="xs:boolean" />
    

    Also make that change to machine readable Governance XSD file


    Already applied
    Issue 88 changed all the BuiltinTopicKey_t to be GUID_t. However it missed some changes, partially because the resolution of Issue#21 added some parameters that thought have also been renamed by 88. As a consequence the following additional changes are needed:

    • Global replace of remote_participant_key with remote_participant_guid in the specification document
    • Global replace of local_participant_key with local_participant_guid in the specification document
    • Global replace of "local participant_key" with local_participant_guid in the specification document
    • Global replace of participant_key with participant_guid in the specification document
    • Replace replace of BuiltinTopicKey_t with GUID_t in the machine readable IDL dds_security_pugin_spis.idl operation validate_remote_identity
    • Global replace of remote_participant_key with remote_participant_guid in the machine readable IDL dds_security_pugin_spis.idl
  • Reported: DDS-SECURITY 1.0 — Fri, 26 May 2017 15:55 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Address identified typos and inconsistencies

    Apply the changes suggested in the issue description.

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

Unnecessary Additional Authenticated Data in common_mac

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

    Current specification defines the followin additional authenticated data when calculating the common_mac:

    • In encode_serialized_payload() the Additional Authenticated Data is empty (9.5.3.3.4.4).
    • In encode_datawriter/reader_submessage the Additional Authenticated Data contains the 4 Bytes in the SEC_SUB_MSG (9.5.3.3.4.5)
    • In encode_rtps_message the Additional Authenticated Data contains the 4 Bytes in the SEC_SUB_MSG (9.5.3.3.4.6)

    It is not clear that this additional step is providing a real gain. We should discuss if we want to change the specification to use an empty additional data in all cases.

  • Reported: DDS-SECURITY 1.0 — Tue, 11 Apr 2017 11:32 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Change Specification to Use Empty AAD

    Change the specification to use an empty AAD.

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

Handling large numbers of receiver-specific MACs

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

    The builtin crypto plugins sign messages with one MAC (common_mac) computed with a key shared with all the DataReaders followed by a sequence of MACs (receiver_specific_macs) each signed with a different key shared with only one DataReader.

    This approach ensures that a DataReader cannot impersonate the DataWriter and sign messages that other readers would validate as originating from the DataWriter.

    This approach results on two issues that need to be addressed:

    • Handling message sizes that approach/exceed the transport MTU
    • Handling large numbers of DataReaders

    The first problem appears because at the time the data sample is written by a DataWriter the DDS implementation needs to know how to fragment it. To do this is uses the known maximum transport MTU as well as knowledge of the overhead due to RTPS headers, etc. This overhead can take into consideration the extra DDS-Security sub-messages. However if the size if the signature depends on the number of matched DataReaders it is not possible to know it at the time the sample is written..

    The second problem appears when we have very large number of matched DataReaders. At some point the overhead of 32 bytes per remote reader starts being excessive in terms of both extra message size as well as the performance to compute each separate MAC.

    The specification should provide some means to handle these issues. A potential approach is this:

    • Allow the DataWriter to be configured with a maximum number of remoter_reader_macs. As long as the number of DateReaders does not exceed it the DataWriter will sign the message with each receiver-specific MAC. Given this maximum the system knows the maximum RTPS overhead and therefore when to fragment large messages.
    • If the number of matched DataReaders exceeds the specified maximum then the DataWriter has two possibilities:

    1. It could reuse the same MACs, that is, share the same receiver-specific Key with multiple DataReaders. This would allow certain reader to impersonate the DataWriter but it will only affect the other readers sharing the same receiver-specific key.

    2. Use a fast digital signature algorithm. This would keep the size of the message fixed and may have additional benefits for messages that are relayed by a persistence service or a routing service

    Looking at the literature of fast digital-signature algorithms one that seems popular is Ed25519. See https://ed25519.cr.yp.to/

  • Reported: DDS-SECURITY 1.0 — Tue, 4 Apr 2017 21:20 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Allow an Endpoint to configure a maximum number of "receiver-specific" MACS

    Specify that a DataWriter can be configured with a maximum number of receiver_specific_macs. As long as the number of matched DateReaders does not exceed it the DataWriter will sign the message with each receiver-specific MAC. Given this maximum the system knows the maximum RTPS overhead and therefore when to fragment large messages.

    If the number of matched DataReaders exceeds the specified maximum then the DataWriter can share the same receiver-specific MACs for more than one reader. This weakens origin authentication. Alternatively the DataWriter could use a different strategy (e.g. send the message multiple times, each limited to the maximum number of receiver_specific_macs) as long as it does not impact interoperability wit receivers that are not aware of this strategy.

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

Inconsistent format for Starting and End Dates in Validity Section

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

    The format of the validity section specified in sub clause 9.4.1.3.2 and 9.4.1.4 are inconsistent with the format specified by the XSD in sub clause 9.4.1.3.

    Conformance to the "xs:dateTime" format requires changes in sub clauses 9.4.1.3.2.2 and 9.4.1.4, but the changes in 9.4.1.4 were already covered by the resolution of DDSSEC11-26.

  • Reported: DDS-SECURITY 1.0 — Wed, 29 Mar 2017 00:37 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicate of DDSSEC11-6

    The problems described in this issue can be solved in DDSSEC11-6.

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

Specify a transformation_kind for BuiltinParticipantVolatileMessageSecure Endpoints

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

    Table 52 - KeyMaterial_AES_GCM_GMAC for BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader defines the following two values for transformation_kind:

    • CRYPTO_TRANSFORMATION_KIND_AES128_GCM
    • CRYPTO_TRANSFORMATION_KIND_AES256_GCM

    This can lead to vendor interoperability issues. The DDS-SECURITY specification should specify one transformation_kind.

    Proposal: use CRYPTO_TRANSFORMATION_KIND_AES256_GCM
    otherwise we would potentially send AES256 keys protected with 128-bit encryption which makes little sense.

  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:21 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Specify a Transformation Kind in Table 52

    Specify changes according to DDSSEC11-53.

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

Wrong description of max_blocks_per_session

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

    Table 58 max_blocks_per_session mentions SessionSalt and SessionHMACKey, which no longer exist. They should be replaced by SessionReceiverSpecificKey.

  • Reported: DDS-SECURITY 1.0 — Tue, 7 Mar 2017 14:30 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Table 58: replace SessionSalt and SessionHMACKey by SessionReceiverSpecificKey.

    Perform the changes suggested in the Issue description

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

check_local_*_match publisher/subscriber partition not present in IDL

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    8.4.2.6 and 8.4.2.6.13 make mention of the publisher/subscriber partition as parameters for the check_local_datawriter_match and check_local_datareader_match functions.
    This parameter is not present in the IDL, and is not covered in 9.4.3 (Table 48).

  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:05 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add Missing parameters to check_local_(datawriter/datareader)_match APIs

    This will implement changes described in DDSSEC11-34

    In addition, we are adding DataTagsQos to the writer & reader qos, to make those symmetric to the info propagated to the wire. This way we can also get rid of tags as parameters in these APIs.

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

AccessControl behavior does not show check_local_datawriter/reader_match operations


Need a way to determine the builtinTopic used for the DataWriter automatic liveliness

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

    As described in 7.4.2 DDS-RTPS defines a the builtin ParticipantMessage topic used to carry two types of Liveliness messages:

    DDS-Security (section 7.4.2) defines a ParticipantMessageSecure that is used to securely send liveliness data messages.

    The Liveliness messages pertain two types of liveliness

    • DataWriter Automatic Liveliness
    • DataWriter Manual by Participant Liveliness

    According to section 7.4.2 both the ParticipantMessage and the ParticipantMessageSecure builtin endpoints should be created but it is not clear whether for a specific DataWriter the liveliness messages should be sent over both or just one of them and if so which...

    This will affect interoperability between vendors and also between an application using DDS-Security and one that is not.

    The specification should clarify this.

  • Reported: DDS-SECURITY 1.0 — Tue, 24 May 2016 02:45 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Apply the modifications suggested in the issue description and comments

    (1) If the Liveliness is "manual by Topic" then liveliness uses Hearbeat submessages associated with the regular DataWriter/DataReader channel so the protection is derived from the DataWriter meta-dataprotection kind. There is no other way to do this.

    (2) If the Liveliness is "manual by Participant" or "automatic" then we would use the ParticipantMessage or ParticipantMessageSecure. In this case we could derive the behavior from the <enable_discovery_protection> setting on the Governance or add a <enable_liveliness_protection>.

    For (2) it seems that tying the selection of the liveliness channel to the enable_discovery_protection would defeat having separate settings for <discovery_protection_kind> and <liveliness_protection_kind> so if we wanted that we should consolidate those two into single setting. So we would need to come up with some common concept for "discovery" and "liveliness" which is not so obvious what that would be.

    Because of this it seems the simplest and most transparent would be to add a <enable_liveliness_protection> under <topic_rule>, and its associated is_liveliness_protected attribute under EndpointSecurityAttributes.

    Also, we are adding a is_liveliness_protected attribute under ParticipantSecurityAttributes, so the "Liveliness Protection Kind" governance element has a clear mapping to a Participant attribute. We do this in a way that is consistent to other mappings (e,g., as the mapping for RTPS protection kind to is_rtps_protected).

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

Inconsistent IDL encode_serialized_data and decode_serialized_data

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

    Document:

    encode_serialized_payload
    (empty) Boolean
    out: encoded_buffer octet[]
    out: extra_inline_qos octet[]
    plain_buffer octet[]
    sending_datawriter_crypto DatawriterCryptoHandle
    out: exception SecurityException

    IDL:

                boolean
                    encode_serialized_data(
                        inout OctetSeq                encoded_buffer,
                        in    OctetSeq                plain_buffer,
                        in    DatawriterCryptoHandle  sending_datawriter_crypto,
                        inout SecurityException       ex);
    

    Name should be changed in the idl to encode_serialized_payload, and we should add missing extra_inline_qos.

    Same issue for decode_serialized_data.

  • Reported: DDS-SECURITY 1.0 — Fri, 21 Jul 2017 08:52 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Change encode_serialized_data/decode_serialized_data in the IDL to be Consistent

    The IDL is wrong, we will fix it to match the rest of the specification.

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

Spec does not explain how t would use different keys for the encode_serialized_payload versus encode_serialized_submessage

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

    The fact that we are calling encode_serialized_submessage on top of the result of encode_serialized_payload allows the use of different key material. This is in fact needed to support the relay mode.

    However the spec is confusing regarding this. In several places (e.g. register_local_datawriter in Table 55) and likewise in create_local_datawroter_cryptotokens seems to indicate that a single KeyMaterial is created.

    This should all be clarified so it is possible to use separate key material for the two operations.

    Seems like this should be stated in register_local_datawriter and register_matched_remote_datareader

  • Reported: DDS-SECURITY 1.0 — Tue, 18 Jul 2017 14:33 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-11 (and its resolution)

    This issue is already handled by the resolution of DDSSEC11-14 (DDSSEC11-126)

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

BuiltinTopicKey_t Inconsistent with current DDS Spec

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

    As also filed under http://issues.omg.org/browse/DDS15-153, current definition used by DDS-SECURITY for BuiltinTopicKey_t is inconsistent with current DDS specification.

    Changing BuiltinTopicKey_t definition would be risky, as multiple implementations may rely on what has been the standard for a long time.

    Also, at this point we should try to avoid changing the wire representation for DDS-SECURITY.

    As a solution that will not break compatibility, we can define a new GUID_t type that is an array of 16 octets, and use this one in the security specification.

  • Reported: DDS-SECURITY 1.0 — Mon, 29 May 2017 16:30 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Replace use of BuiltinTopicKey_t with GUID_t

    To avoid confusion the DDS-Security specification shall use the GUID_t type as defined by the DDS-RTPS specification, and not the BuiltinTopicKey_t.

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

Denial of Service Attack to DDS Security Participants by Injecting Participant Discovery Unregister&Dispose

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

    An attacker could do an easy Denial of Service attack by just injecting Participant Discovery Unregister&Dispose messages.

    Current DDS Security spec does not consider any mechanism to prevent this.

    Proposal

    This proposal allows for checking the authenticity of unregister&dispose messages at the same time that provides a secure way for changing local participant properties after authentication. The proposal is based in adding a new inline qos "PARTICIPANT_SESSION_SIGNATURE" to the Participant Discovery messages from secure participants.

    • The content of the inline qos will be:
      • Two fields for avoiding replay attacks:
        • A NONCE (c.nonce) set to a value generated upon local participant creation.
        • An epoch (c.epoch) incremented each time there is a change in the announced participant discovery information.
      • A signature generated using the private key of the participant. The signature is generated from the following input:
        • c.nonce
        • c.epoch
        • The info state for the sample.
        • (if the sample contains data) md5(c.pData)

    Upon reception of a Participant Discovery Message, and only if the remote participant is authenticated with us, the local participant will check if the received message would trigger a change in the properties or liveliness state of the remote participant. If the received message would trigger a change, the local participant will verify the signature using the certificate of the remote participant. If the verification fails, the message will be ignored. If the verification succeeds, the message will be parsed. In order to make this verification possible, the auth.plugin will expose three new APIs:

    • get_max_private_signature_size: get the max. size of a private signature.
    • private_sign: signs a set of bytes using the local participant private key.
    • verify_private_signature: verifies a set of bytes against a signature using the remote participant public certificate.

    Note: An operation private_sign is a bit too powerful. Would allow the application to sign anything it wants so it is not good practice. The operation should control what kind of data is signed so arbitrary bytes cannot be signed.

    Note that if the remote Participant is not authenticated, no additional checks are done and messages are just parsed as usual.

  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 12:05 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add a DCPSParticipantsSecure buitin Topic

    To address this issue the specification shall add a new builtin Topic to send the ParticipantBuiltinTopicData to authenticated applications. This shall be called the "DCPSParticipantsSecure" builtin Topic.

    After they authenticate the DomainParticipants will ignore data on the (unsecure) "DCPSParticipants" builtin Topic and only process ParticipantBuiltinTopicData data on the "DCPSParticipantsSecure" builtin Topic.

    This topic will be secured the same way as the other secure "discovery" topics.

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

Non Recoverable Communication After Asymmetric Liveliness Loss

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

    After two participants are mutually authenticated and authorized, there are two scenarios that could potentially lead to communication not to recover:

    Let's call the Participant sending token1 "requester" and the Participant sending token2 "replier".

    Scenario 1

    The "replier" participant removes the "requester" participant because of a liveliness loss, there is no way the system can recover:

    • Requester participant still knows about the replier (he did not lose the liveliness), so no AI for him.
    • Replier participant will wait for a request that will never arrive.
    Scenario 2

    The "requester" participant removes the "replier" participant because of a liveliness loss, there is no way the system can recover:

    • Requester participant sends periodic auth messages (token 1).
    • Replier participant still knows about the requester (he did not lose the liveliness), so no AI for him. , It just drop the messages he receives (as if they were duplicates for steps already done) by the replier.

    The problem is, there is no standardized mechanism for triggering a new "Figure 9 - Authentication plugin interaction state machine".

    Other Scenarios

    There may be other scenarios as described in DDSSEC11-81.

    Proposal

    Add a new mechanism that allow triggering the creation of a new Authentication state machine, as we do when we discover a remote participant. In order to do this in a secure way, we need to keep the old authentication session until this new state machine fully succeeds the authentication process. Also, we need to do this in a way an attacker cannot provoke a Denial of Service Attack by continuously triggering re-authentications.

    The proposal here is to solve these problem by adding a new "auth.req" message that asks the remote participant to create a new authentication state machine. If that authentication state machine succeeds, the old one will be replaced:

    • Add a new GMCLASSID (“dds.sec.auth.req”) so it is easly identified as a potential request of restarting the whole authentication process for a participant.
    • If processed (only if the remote participant is authenticated), this request will trigger the creation of a parallel state for a remote participant. This is, would be equivalent to receive discovery pData from new participant. It will therefore trigger the creation of a new authentication state machine.
    • Only if a whole authentication completes, the old remote participant state is removed and the new one triggers the authorization and all the remaining steps.
    • For the request, define a new HandshakeMessageToken ("DDS:Auth:PKI-DH:1.0+AuthReq") containing a NONCE.
    • That NONCE is the random number the Participant mean to use as part of the challenge process. This will be the same challenge will be used as part of the token1 (or token2) we send.
    • Received auth_request will be ignored by peers that are not authenticated with us.
    • Received auth_request will be processed by peers fully authenticated with us, used as a hint about the other remote participant could be willing to restart authentication.
    • Received NONCE will be compared against the random challenge we will receive in the next token1 (or token2). If that matches, means that the remote participant was the one generating the auth_request, so the authentication can continue. If it does not match, we will return VALIDATION_NOT_OK for that token.
    • If the authentication completes, we will remove old state and replace with new one.
    • In order to make the above possible, we need to move the generation of the local challenge to the validate_remote_identity step. That will be stored as part of the remote_identity_handle, so it can be used during the authentication process. Also, if the current state machine was triggered by the reception of an auth.request, we need also to store in the remote_identity_handle the "expected" remote challenge.
  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 11:06 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define New Authentication Request Mechanism

    This proposal will define a new Authentication Request mechanism for requesting for a re-authentication.

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

get_endpoint_sec_attributes inconsistently specified

  • Status: closed   Implementation work Blocked
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    IDL states that there exists one function: get_endpoint_sec_attributes.
    Table 23 lists get_datawriter_sec_attributes and get_datareader_sec_attributes separately.
    As does 8.4.2.6.23/24. (8.4.2.6.23 has a typo in the headline: "dataRwriter")
    Table 48 makes no mention of any of these functions.

  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:24 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Combine with DDSSEC11-16

    This issue affects the same APIs that are being refactored by DDSSEC11-16. Therefore it is best to merge it with that issue.

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

AccessControl::check_create_topic( str_properties ) only present in IDL

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    The parameter "in Properties str_properties" is not covered in the specification document, yet is a parameter in the IDL interface.

  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:01 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Remove extra Properties parameter from check_create_topic in IDL file

    The IDL seems to be the one that is wrong as there the specification does not mention the "properties" parameter on the operation AccessControl::check_create_topic. Consequently the parameter should be removed in the IDL file.

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

GUIDs for new builtin Topics do not comply with DDS-RTPS specification

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

    According to DDS-RTPS specification version 2.2 section 9.3.1.2 (Mapping of the EntityId_t) the last octet of the EntityId_t part of GUID for a builtin DataWriter and DataReader takes a specific value that depends on whether the builtin entity is used to send Topic whose data-type is keyed or unkeyed.

    RTPS uses the name EntityKind to refer to this last octet in the EntityId_t.
    According to Table 9.1 of the DDS-RTPS specification:

    • A builtin DataWriter of a keyed TopicType shall have EntityKind 0xc2.
    • A builtin DataReader of a keyed TopicType shall have EntityKind 0xc7.
    • A builtin DataWriter of a non-keyed TopicType shall have EntityKind 0xc3.
    • A builtin DataReader of a non-keyed TopicType shall have EntityKind 0xc4.

    This is inconsistent with some of the values defines in Table 9 ( section 7.3.7.1) of the DDS-Security 1.0 spec. In particular the following ones:

    • BuiltinParticipantStatelessMessageWriter has EntityKind 0xc2 but it should be 0xc3 because its TopicType has no key.
    • BuiltinParticipantStatelessMessageReader has EntityKind 0xc7 but it should be 0xc4 because its TopicType has no key.
    • BuiltinParticipantVolatileMessageSecureWriter has EntityKind 0xc2 but it should be 0xc3 because its TopicType has no key.
    • BuiltinParticipantVolatileMessageSecureReader has EntityKind 0xc7 but it should be 0xc4 because its TopicType has no key.
  • Reported: DDS-SECURITY 1.0 — Thu, 19 May 2016 02:36 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Correct EntityId_t for the builtin writers and readers of ParticipantStatelessMessage and ParticipantVolatileSecureMessage *

    See Issue description

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

Wrong ValidationResult_t VALIDATION_OK_WITH_FINAL_MESSAGE Used In Multiple Places

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

    The spec defines the retcode VALIDATION_OK_FINAL_MESSAGE in Table 19 and in http://www.omg.org/spec/DDS-SECURITY/20160303/dds_security_plugin_spis.idl.

    However, there are multiple uses of wrong VALIDATION_OK_WITH_FINAL_MESSAGE .

  • Reported: DDS-SECURITY 1.0 — Wed, 5 Oct 2016 13:34 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Replace VALIDATION_OK_WITH_FINAL_MESSAGE Occurrences with VALIDATION_OK_FINAL_MESSAGE *

    Replace the following VALIDATION_OK_WITH_FINAL_MESSAGE with VALIDATION_OK_FINAL_MESSAGE:

    • In Figure 9 – Authentication plugin interaction state machine.
    • In Figure 22 – Authentication sequence diagram with discovered DomainParticipant.
    • In 8.8.2.2 Behavior when allow_unauthenticated_participants is set to FALSE, step 11.
    • In Table 41 – Actions undertaken by the operations of the builtin Authentication plugin:
      • In "process_handshake on a handshake_handle created bybegin_handshake_request"
      • In "get_shared_secret"
      • In "get_authenticated_peer_credential_token"
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Inconsistent Definition of BuiltinLoggingType

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

    BuiltinLoggingType under Figure 20 – Logging Plugin Model (8.6.2 Logging Plugin Model) is not consistent with the IDL in 9.6 Builtin Logging Plugin.

    • facility is an octet in the IDL (a string in the figure).
    • hostname is a string in the IDL (a byte in the figure).
    • IDL contains a field appname. Figure contains procname.
    • procid is a string in the IDL (an int in the figure).
    • msgid is a string in the IDL (an int in the figure).

    Proposal:

    • Update the figure to be consistent with IDL.
  • Reported: DDS-SECURITY 1.0 — Wed, 5 Oct 2016 12:48 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix BuiltinLoggingType under Figure 20 – Logging Plugin Model To be Consistent with IDL

    In Figure 20 – Logging Plugin Model To be Consistent with IDL:

    • Change facility type to octet.
    • Change hostname type to string.
    • Replace procname with appname.
    • Change procid type to string.
    • Change msgid type to string.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

SecurityExceptionCode is undefined

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

    Table 17 – SecurityException class uses the type SecurityExceptionCode without defining it anywhere.

    It seems like it should be defined as a long as it is a 'code' parallel to the 'minor code' which is defined as a long.

    Since SecurityExceptionCode only appears in this table the simples solution is to replace it with a long

  • Reported: DDS-SECURITY 1.0 — Tue, 24 May 2016 01:26 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix Table 17 SecurityException class

    Replace the undefined type 'SecurityExceptionCode' with 'long' in Table 17.

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

Participant's is_access_protected Functionality Overlaps with allow_unauthenticated_participants

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

    In 8.8.6 AccessControl behavior with remote participant discovery, we state:

    If the ParticipantSecurityAttributes object returned by the AccessControl operation
    get_participant_sec_attributes has the is_access_protected attribute set to
    FALSE, the DomainParticipant may discover DomainParticipants that cannot be authenticated
    because they either lack support for the authentication protocol or they fail the authentication protocol.
    These “Unauthenticated” DomainParticipant entities shall be matched and considered
    “Unauthenticated” DomainParticipant entities.

    Also in 8.8.7.1 AccessControl behavior with discovered endpoints from “Unauthenticated” DomainParticipant:

    Note that, as specified in 8.8.2.2, a DomainParticipant for whom the
    ParticipantSecurityAttributes object returned by the AccessControl operation
    get_participant_sec_attributes has the is_access_protected attribute set to
    TRUE, cannot be matched with an “Unauthenticated” DomainParticipant and therefore cannot
    discover any endpoints from an “Unauthenticated” DomainParticipant.

    This is overlapping with allow_unauthenticated_participants. If allow_unauthenticated_participants, then we should allow for unauthenticated participants independently of is_access_protected. In fact, we will not call to any of the AccessControl (nor any other plugin) APIs for that unauthenticated participant.

    For authenticated participants, we should do all the checkings depending on the value for is_access_protected .

  • Reported: DDS-SECURITY 1.0 — Thu, 6 Jul 2017 13:33 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-14 (and its resolution)

    Duplicates DDSSEC11-14 (resolved as DDSSEC11-126)

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

EndpointSecurity's is_payload_protected is Insufficient

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

    Current version of the specification defines is_payload_protected EndpointSecurity attribute. While this is useful for letting the DDS middleware know if it needs to call to security plugin operations for the payload, it is not giving information about the used protection (sign or encrypt).

    This information is needed by the DDS middleware to make a decision about the kind of KeyHash used (see 7.3.4 Mandatory use of the KeyHash for encrypted messages).

  • Reported: DDS-SECURITY 1.0 — Tue, 11 Apr 2017 12:16 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add is_key_protected

    This proposal will add a new EndpointSecurityAttribute: is_payload_obfuscated, so the middleware can take decisions regarding the format for the keyhash.

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

Confusing Sentence about Builtin Endpoints Payload Encryption

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

    In the DDS-SECURITY specification, the following statement could lead to some confusion:

    9.4.1.2.4.4 Discovery Protection Kind element
    The builtin endpoints shall never apply cryptographic transformations to the SecuredPayload
    submessage element.
    

    The wording is not clear. It is suggesting that there should be a SecuredPayload submessage element whose contents are identical to the plaintext, i.e. not transformed.

    It should be changed to something like:

    • The builtin endpoints shall never apply payload-level cryptographic transformations.
  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:45 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Modify Confusing Sentence about Builtin Endpoints

    Change sentence to be more clear.

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

Permissions grant rule with no specified topic

  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The Permissions XSD for the <allow_rule> and <deny_rule> elements allows for zero topics to be specified. In that case, does the rule match ANY topic or NO topics?

  • Reported: DDS-SECURITY 1.0 — Sun, 5 Mar 2017 19:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Modify description of permissions grant rules and XSD

    Make it clear that lacking <publish> Criteria, a rule does not match any topics names for publishing. Likewise lacking a <subscribe> Criteria a rule would match no topics for subscribing.

    These clarifications should be added to 9.4.1.3.2.3.1.2 (Publish Section) and 9.4.1.3.2.3.1.3 (Subscribe Section)

    Modify the XSD for the Permissions document to make the <topics> section mandatory within the <publish> and <subscribe> sections.

    This would impact the omg_shared_ca_permissions.xsd file.
    Also this affects the omg_shared_ca_permissions_example.xml in that the rule below is invalid:

                <allow_rule>
                    <domains>
                        <id>0</id>
                    </domains>
                    <publish>
                    </publish>
                    <subscribe></subscribe>
                </allow_rule>
    

    This rule should be changed to remove the empty <publish> and <subscribe> elements. This change does not modify the meaning of the rule.

    In addition the copy of the example XML that appears in 9.4.1.4 (DomainParticipant example permissions document (non normative)) needs to also be updated.

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

Missing a Way to Pass Participant Data to begin_handshake_request and begin_handshake_reply

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

    We need to pass the local big-endian serialized ParticipantBuiltinTopicData to begin_handshake_request and begin_handshake_reply so that they can include it in the outgoing handshake message as c.pdata (DDS Security spec Tables 38 and 39).

    Proposal is to add a new input parameter to both begin_handshake_request and begin_handshake_reply. That parameter will consist on a buffer with the big endian CDR serialization of the participant data :

    serialized_participant_data octet[]
  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 12:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add serialized_participant_data to begin_handshake_request and begin_handshake_reply

    Add serialized_participant_data to begin_handshake_request and begin_handshake_reply

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

get_*_token should not return non-boolean values

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    Assuming all functions in the AccessControl interface should return a boolean value.

    get_permissions_token and get_permissions_credential_token:
    IDL states a boolean return value, which is also implied by 8.2.4.6.17/18. In both cases the Permissions*Token is an inout parameter.
    Table 23 claims the Permissions*Token is the returned value.

    validate_local_permissions and validate_remote_permissions:
    Stated to return a PermissionsHandle. This is consistent in all sources, so this is perhaps correct, but breaks the pattern.

  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:18 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix get__token in Table 23 To Be Consistent*

    This will move PermissionsToken and PermissionsCredentialToken to the list of regular parameters, and add boolean as return value.

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

Inconsisten ReturnCode NOT_ALLOWED_BY_SEC

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    NOT_ALLOWED_BY_SEC is not prefixed with "RETCODE_".
    This applies to both the IDL and the specification document.

  • Reported: DDS-SECURITY 1.0 — Mon, 3 Oct 2016 07:35 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Rename NOT_ALLOWED_BY_SEC with NOT_ALLOWED_BY_SECURITY

    The document will be changed so that return code NOT_ALLOWED_BY_SEC will be renamed to NOT_ALLOWED_BY_SECURITY.

    The machine-readable IDL file (dds_security_plugins_spi.idl) will be changed to that NOT_ALLOWED_BY_SEC will become RETCODE_NOT_ALLOWED_BY_SECURITY.

    This appears 6 times.

    • Once in the table of content
    • Twice in section 7.2.8
    • Three times in section 8.8.1
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Issue on DDS Security metamodel


Permissions XSD and XML files are inconsistent with normative machine readable file

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

    The normative machine readable XSD file for the permissions document schema here is inconsistent with what is copied into section 9.4.3.1.

    • The root of the XSD document is the element "<dds>" whereas in section 9.4.1.3 and 9.4.1.4 this root is omitted and it jumps directly to the nested subelement "<permissions>."
    • The machine readable XSD is correct as this is also consistent with the format for the Governance file which also has "<dds>" as root.
    • Also the date format in the XSD file is inconsistent with the format that is used in sections 9.4.1.4 and 9.4.1.3.2.2.
  • Reported: DDS-SECURITY 1.0b1 — Fri, 25 Mar 2016 18:12 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fixing inconsistencies with normative machine readable files

    This resolution addresses different inconsistencies between the normative machine readable files and the text of the specification.

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

Unify treatment of builtin endpoints with that of regular endpoints

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

    The security specification introduces several new builtin endpoints, for secure discovery (DCPSPublicationsSecure, DCPSSubscriptionsSecure), secure liveliness (BuiltinParticipantMessageSecure), and Key Exchange (ParticipantVolatileMessageSecure).

    The behavior of these endpoints with regards to the security plugins is controlled by fields in the ParticipantSecurityAttributes, specifically is_discovery_protected and is_liveliness_protected.

    However the behavior of regular (application-defined) endpoints with regards to the security plugins is controlled by the value of the EndpointSecurityAttributes that are specific to each Endpoint.

    This difference in treatment complicates the specification as well as the implementation. It also limits what can be done with the builtin endpoints.

    A better solution would be to reuse the EndpointSecurityAttributes to specify the configuration of the builtin endpoints. This can be done by replacing the is_discovery_protected and is_liveliness_protected booleans with the EndpointSecurityAttributes fields for each type of endpoint as in:

    struct ParticipantSecurityAttributes {
        ....
        EndpointSecurityAttributes discovery_endpoint_attributes;
        EndpointSecurityAttributes liveliness_endpoint_attributes;
        ...
    };
    

    That way the DDS core can treat the builtin endpoints as any other endpoint with regards to security.

    Note that this approach is already followed for the ParticipantVolatileMessageSecureMessage. Its behavior is specified in 7.4.4.2 given its EndpointSecurityAttributes which are hardcoded in the specification.

  • Reported: DDS-SECURITY 1.0 — Wed, 31 May 2017 23:38 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define the TopicSecurityAttributes for the secure builtin topics

    The cryptographic behavior of the secure builtin topics (for example DCPSPublicationsSecure) can be configured via existing elements in the DomainGovernance file. Clearly define how those elements impact the secure builtin topics.

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

Specify Endianness to be Used in Ciphertext

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

    The DDS-SECURITY specification is not specifying the endianness to use in the ciphertext. This can lead to interoperability issues.

    In particular:

    • "9.5.3.3.4.1 Format of the SecureDataHeader Submessage Element" and "9.5.3.3.4.3 Format of the SecureDataTag Submessage Element".
      • Should use the submessage endianness.
    • Section 9.5.3.3.4.2 Format of the SecureDataBody Submessage Element
      • When this is the content of the BODY submessage, the endianness should be the one in the submessage.
      • When this is an encrypted payload, the specification should define a default endianness. Proposal: big endian.

    EDIT
    After the discussion in the comments below, we decided to specify the endianness for the submessage elements to be Big Endian.

  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:22 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Specify Endianness to be Used in Submessage Elements

    Define changes according to the discussion under DDSSEC11-54.

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

Evaluation of data_tags when checking Permissions is unclear

  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    A 'rule' in the Permissions document can include any number of <data_tags> elements. Each data_tags element contains one or more <tag> elements. For example

    <publish>
      <topics><topic>A*</topic></topics>
      <data_tags>
         <tag>
              <name>a</name>
              <value>aVal</value>
         </tag>
         <tag>
              <name>b</name>
              <value>bVal</value>
         </tag>
      </data_tags>
      <data_tags>
         <tag>
              <name>a</name>
              <value>aVal</value>
         </tag>
         <tag>
              <name>c</name>
              <value>cVal</value>
         </tag>
      </data_tags>
    </publish>
    

    The spec should be more clear about the circumstances under which this will and will not match with the tags provided to the check_create_datawriter/reader() and check_remote_datawriter/reader() operations.

    For example, would the above rule match a Writer with the following datatag qos:

     
    { { a, aVal } } 
    

    or:

     
    { {a, aVal}, {b, bVal}, {c, cVal} }
    

    Proposal:
    Add the following statement to the last paragraph of 9.4.1.3.2.3:

    For the data-tag criterion to match, the complete set of tags listed within one of the data_tags elements must match the complete set of data tags associated with the entity in question.

  • Reported: DDS-SECURITY 1.0 — Sun, 5 Mar 2017 20:23 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Clarify the matching criteria for partitions and data_tags

    The matching criteria will be explained. All sections must match.

    • The criteria for the sections within an "allow" rule is that the endpoint partitions/tags are a subset of the ones that are legal.
    • The criteria for the sections within a "deny" rule is that the endpoint partitions/tags cannot overlap any of the ones listed as illegal.

    Conservative defaults will be used when the section is not specified.
    <partitions> within an allow rule defaults to the empty partition
    <data_tags> within an allow rule defaults to no tags
    <partitions> within a deny rule defaults to "*"
    <data_tags> within a deny rule defaults to all tags

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

discovery_protection_kind is Underspecified

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

    In current version of the spec, ParticipantSecurityAttributes only contains is_access_protected and is_rtps_protected.

    To be consistent with other fields like topic_rule's metadata_protection_kind (mapped to is_submessage_protected by the spec) or domain_rule's rtps_protection_kind (mapped to is_rtps_protected by the spec)), we should do the following modifications to the spec:

    • ParticipantSecurityAttributes: add new field is_discovery_protected
      • is_discovery_protected: Indicates the value of is_submessage_protected for the Builtin Discovery Secure endpoints.
    • Discovery Protection Kind element, add the following to 9.4.1.2.4.5 Discovery Protection Kind element:

    This setting controls the contents of the ParticipantSecurityAttributes returned by the
    AccessControl::get_participant_sec_attributes operation on the DomainParticipant. Specifically the is_discovery_protected attribute in the ParticipantSecurityAttributes shall be set to FALSE if and only if the value of the <discovery_protection_kind> element is NONE.

  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 12:13 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define is_discovery_protected ParticipantSecurityAttribute

    Add an entry for is_discovery_protected to Table 21 in section 8.4.2.4. This field controls whether the Crypto plugin operations are called on the DCPSPublicationsSecure and DCPSSubscriptionsSecure.

    Edit section 9.4.1.2.4.4 (Discovery Protection Kind element) to explain that the setting of the <discovery_protection_kind> element determines the value of the ParticipantSecurityAttributes returned by the AccessControl::get_participant_sec_attributes. Specifically the field is_discovery_protected

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

Table 51 CryptoToken should specify endianness of binary properties

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

    Table 51 indicates that the key_material binary property should have as value the CDR serialized representation of a structure but it does not define an Endianness for the serialization. It should.

    Also in 8.3.2.9.4 , 8.3.2.9.5, and 8.3.2.9.6 it talks about message_data being the "cdr serialization" where it is not needed to say anything about serialization.

    Proposal: Use BIg Endian to be consistent with similar decisions on the DDS-Security spec

  • Reported: DDS-SECURITY 1.0 — Tue, 22 Nov 2016 23:39 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Use Big Endian Serialization For Crypto Tokens and To Remove Unnecessary Serialization Details for message_data

    Specify changes to specification according to DDSSEC11-42

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

Inconsistency in SubMessage and SubMessageElement naming throughout document

  • Key: DDSSEC11-7
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:


    Most of the original list of points were addressed as part of the FTF2.
    The remaining two points are copied below:

    ----------------------------------------------------
    7.3.7 – missing section for SecuredPayload SubmessageElement
    Or, [and i think this is better], replace everywhere SecuredPayload with
    SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

    ----------------------------------------------------
    7.3.6.2 RTPS Submessage: SecureSubMsg
    Figure 5 does not show SecureSubMsg.
    Should SecureSubMsg be removed?
    Or maybe it should be used only as a 'generic' term.
    SecureSubMsg is referenced many times in
    "Section 8.8.10 Cryptographic Plugins encoding/decoding behavior".
    Because of this, it might be good to define 'SecureSubMsg' as
    the sequence [ SecurePrefix + SecureBody|SerializedSubMsg + SecurePostfix ].
    Does that work?

    =======================================================
    Original list of points is below
    =======================================================

    ----------------------------------------------------

    7.3.7.4 SecureDataTag Element
    Typo in second para:

    The UDP/IP wire representation for the SecuredPayload shall be:

    Should be

    The UDP/IP wire representation for the SecuredDataTag shall be:

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    7.3.7.8 SecureRTPSPrefixSubMsg Submessage

    Is it true that it contains SecureDataTag?
    It should contain a SecureDataHeader, I think.

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    Mention of TransformationKeyId (section 9.5.2.5) and
    CryptoTransformationKeyId (section 9.5.2.1.1) should
    be CryptoTransformKeyId

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    9.5.2.4 DDS:Crypto:AES-GCM-GMAC SecureDataBody

    Second paragraph "SecureDataTag" should be "SecureDataBody".

    The IDL does not include the 'struct' typename:

    @Extensibility(FINAL_EXTENSIBILITY)
    struct

    { sequence<octet> secure_data; };

    Should be:

    @Extensibility(FINAL_EXTENSIBILITY)
    struct SecureDataBody { sequence<octet> secure_data; }

    ;

    Gerardo: This was already fixed by 182

    ----------------------------------------------------
    9.5.2.5 DDS:Crypto:AES-GCM-GMAC SecureDataTag

    The IDL shows receiver_mac is octet[8], but I think
    it should be octet[16]. 16 bytes is consistent with the
    format shown in 9.5.3.3.4.3.

    Gerardo: Fixed in AB errata
    ----------------------------------------------------
    7.3.7.8 SecureRTPSPrefixSubMsg Submessage

    Message structure shows contents as SecureDataTag. Should be
    SecureDataHeader.

    Gerardo: This was already fixed by 182
    ----------------------------------------------------

    7.3.7 – missing section for SecuredPayload SubmessageElement

    Or, [and i think this is better], replace everywhere SecuredPayload with
    SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

    Gerardo: Too big a change for AB Errata. Push to RTF
    ----------------------------------------------------

    7.3.6.2 RTPS Submessage: SecureSubMsg

    Figure 5 does not show SecureSubMsg.
    Should SecureSubMsg be removed?
    Or maybe it should be used only as a 'generic' term.

    SecureSubMsg is referenced many times in
    "Section 8.8.10 Cryptographic Plugins encoding/decoding behavior".

    Because of this, it might be good to define 'SecureSubMsg' as
    the sequence [ SecurePrefix + SecureBody|SerializedSubMsg + SecurePostfix ].
    Does that work?

    Gerardo: Too big a change for AB Errata. Push to RTF
    ----------------------------------------------------
    7.3.7.5 SecureBodySubMsg Submessage

    Mentions SecureSubMsg, but should be SecureBodySubMsg

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    7.3.7.6 SecurePrefixSubMsg Submessage

    Mentions SecureSubMsg, should be SecurePrefixSubMsg

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    7.3.7.7 SecurePostfixSubMsg Submessage

    Mentions SecureSubMsg, should be SecurePostfixSubMsg

    Gerardo: Fixed in AB errata

  • Reported: DDS-SECURITY 1.0b1 — Sat, 12 Mar 2016 20:21 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Rename SecureDataHeader, SecurePayload, SecureDataTag

    Rename the following submessage elements:
    SecureDataHeader -> CryptoHeader
    SecuredPayload -> CryptoContent
    SecureDataTag -> CryptoFooter

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

Crypto factory plugin implementation key generation

  • Key: DDSSEC11-8
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    After resolution of issue DDSSEC_-182 and -14 , the following issue exists:

    Table 55:

    1) register_matched_remote_participant() description, third sentence is missing sender_key_id.

    This :

    "The TransformationKind, master_salt, and master_sender_key shall match those of the ParticipantKeyMaterial. "

    should read

    "The TransformationKind, master_salt, master_sender_key, and sender_key_id shall match those of the ParticipantKeyMaterial. "

    2. register_matched_remote_datareader(), second sentence.

    This

    "The TransformationKind, master_salt, and master_sender_key for the Writer2ReaderKeyMaterial object shall match those in the DataWriter WriterKeyMaterial."

    should read

    "The TransformationKind, master_salt, master_sender_key, and sender_key_id for the Writer2ReaderKeyMaterial object shall match those in the DataWriter WriterKeyMaterial."

    3. register_matched_remote_datawriter, sentence 2.

    This

    "The TransformationKind, master_salt, and master_sender_key for the Reader2WriterKeyMaterial object shall match those in the DataReader ReaderKeyMaterial. "

    should read

    "The TransformationKind, master_salt, master_sender_key, and sender_key_id for the Reader2WriterKeyMaterial object shall match those in the DataReader ReaderKeyMaterial."

  • Reported: DDS-SECURITY 1.0b1 — Wed, 16 Mar 2016 19:24 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Perform the corrections listed in the issue description

    The issue description contains a number of editing corrections that should be used as the basis for the RevisedText

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

Name of builtin topic is DCPSParticipantMessage not ParticipantMessage

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

    In section 7.4.2 (New ParticipantMessageSecure builtin Topic)
    It talks about the builtin Topic ParticipantMessage the correct name in RTPS spec is DCPSParticipantMessage.

    Consequently the names of the additional builtin Topics introduced by DDS Security should follow a similar naming convention.
    Specifically the following name changes are recommended:

    ParticipantMessageSecure -> DCPSParticipantMessageSecure
    ParticipantStatelessMessage -> DCPSParticipantStatelessMessage
    ParticipantVolatileMessageSecure -> DCPSParticipantVolatileMessageSecure

  • Reported: DDS-SECURITY 1.0b1 — Tue, 19 Jan 2016 01:39 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Correct names of new builtin topics

    Correct the names according to the issue description

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

How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign?

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

    The builtin plugins can be configured via the Governance and Permissions documents to selectively only Sign, or EncryptThenSign different Submessages and SubmessageElements.

    However the specification does not describe the mechanism by which Cryptographic plugin can know what the intent it when it creates the cryptographic material for the different DataWriters and DataReaders.

    The cryptographic material is created by the CryptoFactory operations register_local_datawriter and register_local_datareader. The only parameter that could be used to communicate a decision of Sign versus EncryptThenSign is the Properties parameter. But the specific property names and values to use should be prescribed in the specification.

  • Reported: DDS-SECURITY 1.0b1 — Sun, 3 Jan 2016 17:42 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add EndpointSecurityAttributes Parameter to register_local_datawriter /register_local_datareader

    Add new parameter to register_local_datawriter and register_local_datareader: EndpointSecurityAttributes:

    register_local_datawriter
    (empty) DatawriterCryptoHandle
    participant_crypto ParticipantCryptoHandle
    datawriter_properties PropertySeq
    datawriter_security_attributes EndpointSecurityAttributes
    out: exception SecurityException
    register_local_datareader
    (empty) DatareaderCryptoHandle
    participant_crypto ParticipantCryptoHandle
    datareader_properties PropertySeq
    datareader_security_attributes EndpointSecurityAttributes
    out: exception SecurityException

    As per DDSSEC11-106 (which added plugin_specific_attributes), this will now include all the required information.

    For consistency, similar change proposed to register local participant:

    register_local_participant
    (empty) ParticipantCryptoHandle
    participant_identity IdentityHandle
    participant_permissions PermissionsHandle
    participant_properties PropertySeq
    participant_security_attributes ParticipantSecurityAttributes
    out: exception SecurityException
  • Updated: Tue, 19 Dec 2017 20:03 GMT

DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear

  • Key: DDSSEC11-2
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The description refers to the "liveliness protection element", which seems like an error.

    The description further says that this element specifies "the protection kind (see 9.4.1.2.1) used for the whole RTPS message". It is not clear to which message this refers.

  • Reported: DDS-SECURITY 1.0b1 — Sat, 21 Nov 2015 18:27 GMT
  • Disposition: Closed; No Change — DDS-SECURITY 1.1
  • Disposition Summary:

    Issue already corrected in the FTF

    This issue was corrected by http://issues.omg.org/browse/DDSSEC_-35

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

Complexity of Authentication Plugin Model

  • Key: DDSSEC11-1
  • Legacy Issue Number: 19793
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. 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
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer

    The issue does not affect the interoperability or behavior. The many benefit would be to simplify the explanation and potentially the implementation of the Authentication plugins. However addressing would be complex in terms of the amount of text that would be affected and the interactions with the text modified by other issues in this RTF.

    For this reason it seems most appropriate to defer it to the next RTF. At that point there will be less changes caused by other issues thus simplifying the resolution of this issue

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

Miscellaneous typos/inconsistencies

  • Key: DDSSEC11-5
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:
    • In section 9.6 (BuiltinLoggingPlugin) it says "NameValurPair" it should say "NameValuePair"
    • In Figure 20 field "msgid" is "int" it should be "string" to be consistent with section 9.6
    • In section 9.4.1.2 there are two occurrences of "Encrypt+MAC" this is ambiguous as it could be interpreted as "Encrypt and MAC" which s not considered best practice. It should say "Encrypt-then-MAC" to be more precise and match what the plugins do.
    • Section 9.4.1.2.5.5 second paragraph says "This element may take the binary values TRUE or FALSE" instead it should say "This element may take the three possible values: NONE, SIGN, or ENCRYPT.''
    • Section 4, definition of Key management. Remove the words "of the keys" from the definition as shown here: "...during their entire life cycle of the keys from creation to destruction."
    • XML examples in Section 9.4.1.2.7 and 9.4.1.4 use encoding="utf-16" this should be changed to encoding="utf-8" to be consistent with the XSD in section 9.4.1.2.2, 9.4.1.3, and all the machine readable documents (both XSD and example XMLs).
    • Section 9.4.1.2.4.5 (Liveliness Protection Kind element) in the 3rd and last paragraph says: "The discovery protection kind..." it should say "The liveliness protection kind..."
  • Reported: DDS-SECURITY 1.0b1 — Mon, 28 Mar 2016 23:47 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Perform the corrections listed in the issue description

    The issue description contains a list of corrections that should become the RevisedText

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

Examples of Wildcard permissions

  • Status: closed  
  • 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
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Examples would be nice but can be deferred

    Having example permission files would help implementors of the specification so it is considered a desirable feature.

    However given the limited time to complete the RTF 1 the task force decided to defer to the next RTF

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

How is single-MAC versus MAC-per-reader configured?

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

    Currently the governance document allows specification of a "protection_kind" which can be NONE, SIGN, ENCRYPT

    But we support a single MAC versus multiple MACs (one per reader). Who configures this. Is this something in the Governance document? Something that appears in the Permissions document of the DataReader?

    Also it should be stated in the specification that if a DataReader gets in its KeyMaterial from the DataWriter a "receiver_specific_keyid" then it shall expect that messages from that DataWriter are signed with the reader-specific key and if it is not so they shall be rejected.

  • Reported: DDS-SECURITY 1.0b1 — Sat, 20 Feb 2016 01:45 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Extend governance to indicate whether mac_per_readers are desired

    Note: This is work in progress (see comments at bottom of DDSSEC11-11 for issues still being resolved)

    The format of the Governance document of the builtin Authentication plugin shall be extended.

    • There shall be a new ExtendedProtectionKind simple type that is is similar to the existing ProtectionKind enumeration except with extra values: ENCRYPT_WITH_ORIGIN_AUTHENTICATION and SIGN_WITH_ORIGIN_AUTHENTICATION
    • The type associated with the <rtps_protection_kind>, <metadata_protection_kind>, <discovery_protection_kind> and <liveliness_protection_kind> shall be changed to be ExtendedProtectionKind instead of the current ProtectionKind

    The selection of ExtendedProtectionKind SIGN_WITH_ORIGIN_AUTHENTICATION or ENCRYPT_WITH_ORIGIN_AUTHENTICATION indicates that in addition to the common authentication code there shall be an additional authentication code that uses the reader-specific MAC key.

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

Provide mechanisms to extend Governance and Permissions files without breaking interoperability

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer to RTF2

    This issue has been deemed of lower priority and some of the proposals to address it depend on standards that are not widely supported. Hence the RTF has determined to defer it to the next RTF in the hope that the situation and requirements will be more clear by then.

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

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

  • Key: DDSSEC11-9
  • Status: closed  
  • 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
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer to RTF2

    Making the different interfaces independent from each other is a desirable goal. But it may require some additional changes beyond the ones mentioned in this issue description. For this reason the RTF decided to postpone it to the next RTF.

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

Determining the wire version of the DDS Security Protocol

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

    In the case of the DDS-RTPS wire protocol, the version of the RTPS protocol can be determined from the RTPS header that starts each message.

    DDS-Security adds messages to RTPS. In that sense it extends the protocol creating an SRTPS protocol (with additional builtin endpoints, submessages, and submessage elements). However there does not seem to be an obvious way to determine this version from just observing the packets on the wire.

    Not having this version may complicate creating future revisions that do not break interoperability and also the development or use of packet level tools like wireshark.

    One possible solution is to use the minor version of the RTPS protocol to also encode the version of the secure RTPS protocol. For example current version of RTPS is 2.2 we could say that from now onwards the "odd" version numbers represent "secure" versions of the proceeding "even" version. So the result of DDS Security RTF 1 will be RTPS 2.3 and the result of DDS Interoperability RTF3 will be RTPS 2.4. If these RTFs do not alternate we just skip the intermediate version. For example if DDS Interoperability RTF4 comes without an interweaving DDS-Security we just jump to RTPS 2.6

    Proposal:
    This DDS-Security RTF will cycle the version of RTPS to the next (2.3)
    The current RTPS RTF3 will take that into consideration and indicate the range of sub-messages reserved for security. RTPS RTF3 will then set the RTPS protocol version to "2.4"

    Onwards each RTF will update the RTPS version (assuming there are changes to the protocol) because they should know about each other.

    In addition we need to say that the Plugin name has the version as part of the name and that the version should be parsed in a certain way to check compatibility. I.e. not require an exact match of the plugin names.

    We should also add a "version" properties for each plugin as in dds.sec.auth.version and dds.sec.access,version, these would be propagated.
    Also add a dds.sec.auth.common to have an overall version of the spec...

  • Reported: DDS-SECURITY 1.0 — Wed, 31 May 2017 16:55 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Revise version of RTPS and provide rules for plugin versions

    Since the DDS-Security specification adds new RTPS submessages it should also update the version of RTPS to the next one (2.3).

    The DDS-Security should spec should also "reserve" a range of RTPS Discovery parameterIds 0x1XXX for the use of the DDS-Security spec and future revisions.

    Section 9.3.2 (DDS:Auth:PKI-DH Types) should indicate that the IdentityToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
    <PluginClassName>:<MajorVersion>.<MinorVersion>
    If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not attempt authentication.

    Section 9.4.2.2 (DDS:Access:Permissions PermissionsToken) should indicate that the PermissionsToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
    <PluginClassName>:<MajorVersion>.<MinorVersion>
    If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not try to interpret the permissions document of the other participant.

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