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

Open Issues

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

Issues Summary

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

Issues Descriptions

Additional typos/inconsistencies

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



    Consider renaming enable_strict_permission_formatting (from DDSSEC11-14) to be something else and specify that it also impacts processing of the Governance 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
  • Updated: Thu, 27 Jul 2017 11:03 GMT

Provide mechanisms to extend Governance and Permissions files without breaking interoperability

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

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

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

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

    Some possibilities:

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

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

  • Reported: DDS-Security 1.0b1 — Sat, 20 Feb 2016 01:36 GMT
  • Updated: Wed, 26 Jul 2017 09:28 GMT
  • Attachments:

AccessControl::check_create_topic( str_properties ) only present in IDL

  • Status: open  
  • Source: Kongsberg Geospatial ( 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
  • Updated: Wed, 26 Jul 2017 07:54 GMT

Clarify conditions for calling the operations on AccessControlPlugin

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:38 GMT

Inconsistent IDL encode_serialized_data and decode_serialized_data

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:36 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:36 GMT

begin_handshake_request in the IDL Not Consistent with the Main Document

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:36 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:36 GMT

Examples of Wildcard permissions

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

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

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

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

  • Reported: DDS-Security 1.0 — Tue, 11 Jul 2017 12:43 GMT
  • Updated: Tue, 25 Jul 2017 16:36 GMT
  • Attachments:

No mechanism to free ParticipantSecurityAttributes or EndpointSecurityAttributes

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:36 GMT

Unclear Effectiveness of is_rtps_protected=true allow_unauthenticated_participants=true

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:36 GMT

Participant's is_access_protected Functionality Overlaps with allow_unauthenticated_participants

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

Non-Recoverable Communication After Authentication Session Terminated

  • Status: open  
  • 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

Permissions grant rule with no specified topic

  • Status: open  
  • Source: Twin Oaks ( 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

Correct Figure 9 to match description of the authentication protocol

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

get_endpoint_sec_attributes inconsistently specified

  • Status: open   Implementation work Blocked
  • Source: Kongsberg Geospatial ( 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

get_*_token should not return non-boolean values

  • Status: open  
  • Source: Kongsberg Geospatial ( 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

check_local_*_match publisher/subscriber partition not present in IDL

  • Status: open  
  • Source: Kongsberg Geospatial ( 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

SecurityExceptionCode is undefined

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:35 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 25 Jul 2017 16:34 GMT

Handling expiration of Permissions or Certificates during operation

  • Status: open  
  • Source: Twin Oaks ( 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
  • Updated: Fri, 21 Jul 2017 15:33 GMT

Evaluation of data_tags when checking Permissions is unclear

  • Status: open  
  • Source: Twin Oaks ( 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
  • Updated: Tue, 18 Jul 2017 16:23 GMT

Unify treatment of builtin endpoints with that of regular endpoints

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

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

    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
  • Updated: Tue, 18 Jul 2017 13:37 GMT

AccessControl behavior does not show check_local_datawriter/reader_match operations

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

    Section 8.8.7.2 (AccessControl behavior with discovered endpoints from Authenticated DomainParticipant) and Figure 26 there show the operations on the AccessControl plugin that are called as a result of discovering a remote entity.

    These sequence diagrams and Figure show when check_remote_datawriter and check_remote_datareader are called but do not mention the calls to check_local_datareader_match and check_local_datawriter_match

    The calls to these operations should be added to the sequence diagram and descriptive text.

  • Reported: DDS-Security 1.0 — Tue, 24 May 2016 01:46 GMT
  • Updated: Fri, 14 Jul 2017 18:48 GMT

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

  • Key: DDSSEC11-6
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Fri, 14 Jul 2017 18:04 GMT

Inconsisten ReturnCode NOT_ALLOWED_BY_SEC

  • Status: open  
  • Source: Kongsberg Geospatial ( 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
  • Updated: Fri, 14 Jul 2017 15:25 GMT

Handling large numbers of receiver-specific MACs

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Fri, 14 Jul 2017 14:33 GMT

Should differences in EndpointSecurityAttributesMask prevent matching?

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Fri, 14 Jul 2017 14:30 GMT

Non Recoverable Communication After Asymmetric Liveliness Loss

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Thu, 13 Jul 2017 01:10 GMT

OCSP stapling to enhance certificate status checking during handshake

  • Status: open  
  • 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.

  • Reported: DDS-Security 1.0 — Mon, 22 May 2017 06:40 GMT
  • Updated: Sat, 8 Jul 2017 07:29 GMT

BuiltinTopicKey_t Inconsistent with current DDS Spec

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT
  • Attachments:

Determining the wire version of the DDS Security Protocol

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

dds_security_plugins_spis.idl has inheritance commented out

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

Missing a Way to Pass Participant Data to begin_handshake_request and begin_handshake_reply

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT
  • Attachments:

EndpointSecurity's is_payload_protected is Insufficient

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT
  • Attachments:

Confusing Sentence about Builtin Endpoints Payload Encryption

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

VALIDATION_PENDING_CHALLENGE_MESSAGE

  • Status: open  
  • Source: Kongsberg Geospatial ( 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT
  • Attachments:

Remove duplicate of RTPS message inside the security envelope

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

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

  • Status: open  
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

Normative IDL does not match documentation for Authentication::validate_remote_identity

  • Status: open  
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

FIPS-196 reference to wrong chapter

  • Status: open  
  • Source: Kongsberg Geospatial ( 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear

  • Key: DDSSEC11-2
  • Status: open  
  • Source: Twin Oaks ( 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

Inconsistency in SubMessage and SubMessageElement naming throughout document

  • Key: DDSSEC11-7
  • Status: open  
  • Source: Twin Oaks ( 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT
  • Attachments:

Name of builtin topic is DCPSParticipantMessage not ParticipantMessage

  • Key: DDSSEC11-4
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 8 Jul 2017 00:12 GMT

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

  • Key: DDSSEC11-3
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Thu, 6 Jul 2017 21:21 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 6 Jun 2017 14:10 GMT

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

  • Key: DDSSEC11-9
  • Status: open  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

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

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

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

  • Reported: DDS-Security 1.0b1 — Tue, 1 Mar 2016 17:36 GMT
  • Updated: Tue, 23 May 2017 15:27 GMT

Wrong description of max_blocks_per_session

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Unnecessary Additional Authenticated Data in common_mac

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Inconsistent format for Starting and End Dates in Validity Section

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Specify Endianness to be Used in Ciphertext

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Specify a transformation_kind for BuiltinParticipantVolatileMessageSecure Endpoints

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Apply sha256 to derived shared secret

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Specify Authentication Challenge Length

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Wrong Facility Value for Logging Plugin

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

discovery_protection_kind is Underspecified

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Table 51 CryptoToken should specify endianness of binary properties

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Need to specify format of SubjectName used for adjusted_participant_key

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Inconsistent Behavior for Secure Volatile Endpoints

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Wrong ValidationResult_t VALIDATION_OK_WITH_FINAL_MESSAGE Used In Multiple Places


Inconsistent Definition of BuiltinLoggingType

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT
  • Attachments:

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Crypto factory plugin implementation key generation

  • Key: DDSSEC11-8
  • Status: open  
  • Source: Twin Oaks ( 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Invalid domain_id tag used in multiple sections of the spec

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT

Miscellaneous typos/inconsistencies

  • Key: DDSSEC11-5
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Tue, 2 May 2017 00:37 GMT


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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Sat, 17 Sep 2016 00:19 GMT

Complexity of Authentication Plugin Model

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

    The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

    • It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
    • The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
    • There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
    • It is difficult to determine at which sense a received message belongs
    • In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

    This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

    Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

    Instead, we suggest to remove it and to change the mechanism to the following:

    • remove all the "_handshake" methods on the Authentication Plugin
    • add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
    • add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
    • add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
    • add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
    • once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

    This will provide the necessary functionality in a much simple, efficient and robust manner.

  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:35 GMT