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

DDS Security 1.0 FTF 2 — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSSEC_-134 Builtin Access Control - Inadequate Validity datatypes in permissions schema DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-182 Clean-up encode_serialized_payload and decode_serialized_payload DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-166 Typos in DDS Security DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-165 Document security error conditions and log messages DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-172 Update Figures to match new submessages introduced in DDSSEC-14 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-164 Use standard Key Derivation functions from the SharedSecret DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-178 Remove spurious references to PermissionCredential DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-176 Additional Enhancement to Mutual Authentication following ISO/IEC 9798-3 standard DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-146 Enhance security of the Authentication Handshake DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-14 More explicit Authentication and Permissions configuration DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-168 Use standard format for subject name in permissions and identity DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-169 Use standard format for subject name in permissions and identity DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-127 (meta)data_protection_kind takes incorrect values DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-130 The example governance does not validate with the governance XSD DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-133 Builtin Access Control - Use of 'TopicExpression' in Domain Governance DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-136 Builtin Access Control - Useless BooleanKind in Domain Governance Schema DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-144 Typo - KxKeyCookie/KxCookie and KxMacCookie/KxMacKeyCookie DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-143 adjusted_participant_key renamed to effective_participant_key without notice DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-142 Typo CryptoTranformIdentifier instead of CryptoTranSformIdentifier DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-76 Construction of HandshakeRequestMessage is unclear DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-75 In DomainGovernance, what is default behaviour if a domain+topic topic_rule is not found DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-78 Contents of KeyMaterial_AES_CTR_HMAC structure unclear DDS-Security 1.0b1 DDS-Security 1.0 Closed; No Change closed
DDSSEC_-139 In DomainParticipant permissions XSD: minOccurs of in DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-36 Parameters of get_endpoint_sec_attributes DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-34 Parameters of get_participant_sec_attributes DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-33 Builtin Authentication plugin: RSA or DSA ? DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-27 PermissionsCredential in validate_local_permissions DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-29 Plugins per-process or per-participant ? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-122 Default permissions for partitions are too broad DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-135 Builtin Access Control - Useless BooleanKind in Domain Governance Schema DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-137 Builtin Access Control - Inadequate XML type for 'domainId' in schemas DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-107 Wrong reference to "create_local_datawriter_crypto_tokens" and "create_local_datareader_crypto_tokens" in §8.8.6.3 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-106 Typos in DDS-Security Specification (2) DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-104 Inconsistent naming "SingleSubmsgFlag", "SingleSubmessageFlag" versus "MultiSubmsgFlag" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-109 Wrong reference to check_create_datareader in §9.4.1.2.5.4 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-108 Wrong reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-114 Size of NONCE (Challenge_A/Challenge_B) in Authentication handshake messages undefined DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-73 How to determine if creating a DomainParticipant is allowed DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-72 Use of 'partition' in access control is unclear DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-74 Is there implicit handling for builtin secure endpoints in the access control plugin? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-35 Builtin Access Control plugin doesn't set is_rtps_protected DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-32 Which encryption algorithm for the SharedSecret ? DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-7 In Table 18: check_remote_datawriter() should have a subscriber_partition parameter DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-5 Announcement of the new secure builtin endpoints DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-18 Handle types are shared by some plugins DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-1 In register_matched_remote_datareader() relay_out parameter should be IN DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-97 Errors in §8.8.6.4 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-96 Errors in 8.8.5.2 step 6, step 7, and step 11 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-95 Typos in DDS-Security Specification DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-103 Replace encode_serialized_data with encode_serialized_payload DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-98 §8.8.7.1, §8.8.7.2, §8.8.7.3: "received by the BuiltinParticipantVolatileMessageSecureWriter" should be "received by the BuiltinParticipantVolatileMessageSecureReader" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-82 9.4.1.2.5 Governance Document description typo DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-81 Data type for CryptoTransformIdentifier.transformation_kind_id is unclear DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-80 Do the encode operations prefix the CDR data with a CDR encapsulation header? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-79 Parameters to register_matched_remote_datareader() inconsistent between spec and IDL. DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-77 Description of HandshakeReplyMessage has an error DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-57 Section 8.3.2.9.1 (Authentication plugin interface) should not be under 8.3.2.9 (Unauthenticated DomainParticipant entities) DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-38 The padding used when encrypting the shared secret is not specified DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-11 Confusion between is_access_protected and allow_unauthenticated_participants DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-10 Matching of ParticipantStatelessMessage builtin endpoints DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-8 In Figure 12: preprocess_rtps_submessage() should be preprocess_secure_submsg() DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-3 Replace "BuiltinParticipantStatelessMessager" with "state-machine" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-4 The adjusted_participant_key must be a valid Participant GUID DDS-Security 1.0b1 DDS-Security 1.0 Closed; No Change closed
DDSSEC_-6 In Table 1 and Table 2: the "name" attribute should be renamed as "key" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-9 In Table 18: check_create_topic should not have a "property" parameter DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-19 register_matched_remote_datawriter: wrong parameter name DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-31 Content of initialization_vector and hmac_key_id DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-30 New callback for authentication failures DDS-Security 1.0b1 DDS-Security 1.0 Closed; No Change closed
DDSSEC_-23 Benefit of session keys: wrong sentence DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-26 How to find the MasterSessionSalt to decrypt ? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-25 Typo in KeyMaterial_AES_CTR_HMAC: initilization_vector DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-24 CipherKind and HashKind enums both use NONE DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-21 Meaning of MasterHMACSalt DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-20 Extra parameter to register_local_datawriter DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-13 validate_remote_permissions cannot return TRUE DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-12 Typo: is_discoverye_protected DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-17 Value of HandshakeRequestMessageToken 1st property DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-16 Inconsistency between "BuiltinParticipantStateless" and "InterParticipantStateless" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-15 Wrong bits indexes in effective_participant_key DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-28 Complexity of Authentication Plugin Model DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-22 Meaning of SessionId DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-128 How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign? DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-83 DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-140 Name of builtin topic is DCPSParticipantMessage not ParticipantMessage DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-187 Permissions XSD in section 9.4.1.3 and example in 9.4.1.4 are inconsistent with normative machine readable file DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed

Issues Descriptions

Builtin Access Control - Inadequate Validity datatypes in permissions schema


Clean-up encode_serialized_payload and decode_serialized_payload


Typos in DDS Security

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

    This issue gathers miscellaneous types in the spec

    For example, in 8.8.3 (DDS Entities impacted by the AccessControl operations) first paragraph is says "five types" when it should say "six types"

  • Reported: DDS-Security 1.0b1 — Thu, 11 Feb 2016 19:36 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix miscellaneous typos and issues in spec.

    The purpose of this issue is to provide the ability to correct small typos and issues that remain after application of the resolution of ll other issues in the FTF.
    It is a catch-all for small unrelated tasks that avoids having to reopen each issue or the complication of managing many issues separately

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Document security error conditions and log messages


Update Figures to match new submessages introduced in DDSSEC-14


Use standard Key Derivation functions from the SharedSecret

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

    It appears that using the HMAC() by itself is not recommended in the case the shared secret Z comes from a diffie-hellman exchange because the DH-generated secrets are not random enough. It would be OK with the RSA approach if the secret was generated using a cryptographically-strong random number.

    The accepted way to derive keys from a "shared secret" is called a HMAC-based Key Derivation Function. As it turns out there is a great paper on this (http://eprint.iacr.org/2010/264.pdf) which was the basis for a recent IETF (informational) standard:
    https://tools.ietf.org/html/rfc5869

    This paper describes the pitfalls of using just a hash-function to generate keys from with DH shared secrets. It also criticizes some of the NIST recommendations because they are also "weak".

    The recommendation is to follow what https://tools.ietf.org/html/rfc5869 as it is a well stablished approach used by IKE and it is better than the simple HMAC the specification is using.

    Their recommended approach is along the lines of HMACsha256(Challenge_A # Challenge_B # Cookie, SharedSecret). However there is a twist. Rather than repeat this approach using different Cookies they recommend using the result of the above just as a first step, and then "expand on it" as in:

    Note: First argument to HMAC-sha256() function is the key material.

    PRK = HMAC-sha256(NonSecretSalt, SharedSecret)
    T(0) = "" (empty-zero length string)
    Cookie = "
    T(1) = HMAC-sha256(PRK, T(0) | Cookie | 0x01)
    T(2) = HMAC-sha256(PRK, T(1) | Cookie | 0x02)
    T(3) = HMAC-sha256(PRK, T(2) | Cookie | 0x03)

    The resulting material T = T(1) | T(2) | T(3) | T(4)
    is then used to get the needed keys and salts.
    In our case we would need: KxKey, KxSalt

    We could use, following RFC 5869:

    NonSecretSalt = Sha256(Challenge_A # Challenge_B # "key exchange")
    PRK = HMAC-sha256(NonSecretSalt, SharedSecret)

    KxKey = HMAC-sha256(PRK, KxKeyCookie | 0x01)
    KxSalt = HMAC-sha256(PRK, KxSaltCookie | 0x02)

    In addition it seems like our SessionKeys, SessionSalt, and SessionHMacKey may suffer from the same problem. they are using the secret (MasterKey) as the key to the HMAC instead of as the "payload".
    Perhaps we should also modify this to align it with RFC 5869

    This change would be limited to:

    Table 50 ( KeyMaterial_AES_GCM_GMAC for BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader )

    And Section 9.5.3.3.3 (Computation of SessionSenderKey and SessionReceiverSpecificKey)

  • Reported: DDS-Security 1.0b1 — Thu, 11 Feb 2016 14:25 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Use a HKDF to obtain the key material from the DH shared secret

    Follow the approach recommended in IETF RFC 5869https://tools.ietf.org/html/rfc5869

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Remove spurious references to PermissionCredential

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

    The PermissionCredential type was removed from the spec by issues and 166. However, there are still a couple of references to it that should be removed.

    8.3.2.8 (Table 20), 8.3.2.8.10, 8.4.2.6.1, 8.8.1 (item 5), 8.8.2.2 (item 16 and 18), 8.8.6 (item 1 and 2), 9.4.3 (Table 47)

    The dds_security_plugin.idl operation set_permissions_credential_and_token()

  • Reported: DDS-Security 1.0b1 — Mon, 15 Feb 2016 18:47 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Remove the spurious references to PermissionCredential

    See issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Additional Enhancement to Mutual Authentication following ISO/IEC 9798-3 standard

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

    Note: this issue was raised by Cyril Dangerville (THALES).

    Despite the enhancement in DDSSEC_-146 the Authentication protocol still has an "identity misbinding issue".

    The protocol after DDSSEC_-14 is applied can be summarized as:

    Revised (recommended) protocol:
    
    Participant1                                                       Participant2
    
    
                                   ParticipantDiscovery (pdata)
                      <------------------------------------------------------------
    
    Message 1: 
    c_1, Hash(c1), challenge_1
    --------------------------------------------------------------------------->
    
                       Message 2: 
    c_2, Hash(c_2) | dh_2 | challenge_1 | challenge_2, 
                      	Sign(Hash(c_2) | dh_2 | challenge_1 | challenge_2 ) )   
           <------------------------------------------------------------------------------
    
    Message 3:
     Hash(c_1), dh_1, challenge_1, challenge_2,
             Sign(Hash(c_1) | dh_1 | challenge_1 | challenge_2)
    -------------------------------------------------------------------->
    

    This protocol is vulnerable to Unknown Key Share (UKS), aka identity misbinding attack. Let participant P3 (with c_3 = id_3, etc.) be an attacker in the middle.
    P3 intercepts message 1 and replaces with the message below before transfering to P2:

    c_3, Hash(c_3), challenge_1
    

    P2 then replies message 2 and P3 transfers the message to P1 unchanged.

    P1 replies message 3 but P3 intercepts again and replaces with the message below before transfering to P2:

    Hash(c_3), dh_1, challenge_1, challenge_2,
    		Sign_P3(Hash(c_3) | dh_1 | challenge_1 | challenge_2)
    

    In the end, P1 and P2 are the only ones sharing the secret (K) based on dh_1 and dh_2 as only P1 and P2 know the private values. However, P2 believes its peer to be P3 since he received (and could validate) only the certificate and signature of P3. Therefore, P2 believes he is sharing a key with P3, whereas he is actually sharing with P1. From then on, any subsequent message arriving to P2 and authenticated under K - or keys derived from it - will be interpreted by P2 as coming from P3. Note that this attack does not result in a breach of secrecy of the key (since the attacker does not learn, nor influence the key in any way), but it does result in a breach of authenticity since the two parties to the exchange will use the same key with different understandings of who the peer to the exchange is.

    To avoid this the protocol should be modified to something like this:

    Protocol flow:
    P1 <- P2: ParticipantDiscovery (pdata)                                                                                             
    P1 -> P2: c_1, challenge_1, dh_1
    P1 <- P2: challenge_1, c_2, challenge_2, dh_2,
               SignP2(Hash(c_2)|challenge_2|dh_2|challenge_1|dh_1|Hash(c_1))
    P1 -> P2: challenge_1, 
                SignP1(Hash(c_1)|challenge_1|dh_1|challenge_2|dh_2|Hash(c_2))
    
  • Reported: DDS-Security 1.0b1 — Mon, 15 Feb 2016 01:11 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify authentication protocol to avoid the Identity Misbinding Attack

    The authentication protocol should be modified to make it robust to the Identity Misbinding Attack. The approach shall follow what was suggested in the issue description with some minor additions that make it easier to implement in an interoperable manner.

    The modified protocol (including suggested optional properties) is:
    The notation [ xxx ] indicates properties that may be present for troubleshooting purposes but otherwise can be omitted.

    P1 <- P2: ParticipantDiscovery (pdata)
    P1 -> P2: c_1, [Hash(c_1)], challenge_1, dh_1
    P1 <- P2: c_2, [Hash(c_2)], challenge_1, challenge_2, dh_2, [Hash(c1)], [dh_1]
              SignP2(Hash(c_2) | challenge_2 | dh_2 | challenge_1 |dh_1 | Hash(c_1) ) 
    P1 -> P2: [Hash(c_1)], [Hash(c_2)], [dh_2], [dh_1], challenge_1, challenge_2,     
              SignP1(Hash(c_1) | challenge_1 | dh_1 | challenge_2 | dh_2 | Hash(c_2)) 
    
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Enhance security of the Authentication Handshake

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

    The mutual authentication handshake described in 9.3.2 does not validate the ParticipantBuitinTopicData exchanged via discovery. This can create some vulnerability.
    In addition the messages contain Information that is not being by the sender nor confirmed by the receiver. This includes the IdentityCertificates and Permissions, and other data. This is not considered best practices. Nominally each message in the handshake should tie-in to the previous message.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Feb 2016 13:14 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Enhance Authentication handshake

    Enhance Handshake to follow best practices from NIST FIPS-196
    http://csrc.nist.gov/publications/fips/fips196/fips196.pdf

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

More explicit Authentication and Permissions configuration

  • Key: DDSSEC_-14
  • Legacy Issue Number: 19777
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.3.2.9.3 the IdentityCredential parameter passed to the validate_local_identity operation is described as following:
    "The nature and configuration of the credential is specific to each Authentication plugin implementation"

    In §8.3.2.1:
    "The specific content of the IdentityCredential shall be defined by each Authentication plugin specialization and it may not be used by some Authentication plugin specializations. The interpretation of the contents as well as the mechanism used to pass it to the Authentication plugin shall be specified by each plugin implementation.”

    In §9.3.2.1:
    "The DDS:Auth:PKI-RSA/DSA-DH plugin shall set the attributes of the IdentityCredential objects as specified in the table below."

    So it seems it's up to the AuthenticationPlugin to create the IdentityCredential (it's the only one to know how to set/interprate the attributes). Moreover, we could imagine the credential to be provided by various ways which are specific to the AuthenticationPlugin implentation (e.g. security hardware as USB Credential Provider or fingerprint reader...)

    Nevertheless, the middleware is supposed to pass the IdentityCredential to the validate_local_identity operation. But it has no way to create or get this IdentityCredential object.

    We suggest to replace this IdentityCredential parameter with the DomainId and the QoS Policies of the DomainParticipant to validate. Thus, the AuthenticationPlugin has a way to make distinction between 2 local DomainParticipant to validate, and can internally applies different credentials.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Specify how to configure authentication and access control plugins. Also specify which cryto families shall be supported

    The resolution of this issue should is to define the configuration of the Authentication and Permissions plugins more explicitly such that they can be “plugged” in across vendors without requiring changes to the core DDS.

    Doing this requires a general-purpose mechanism to configure the plugins from DDS. This is accomplished by adding a PropertyQosPolicy to the DomainParticipantQos consisting of Name-Value pairs. This reuses the “Property_t” type already defined in 7.2.1 making it a “first-class” element within the DomainParticipantQos and also visible via discovery.

    The parameters to Authentication::validate_local_identity() and AccessControl::validate_local_permissions() need to be adjusted to receive those properties.

    Support for the following crypto families should be specified:
    Identity/Authentication: RSA-2048 and Elliptic Curve prime256v1with
    SharedSecret: Diffie-Hellman and Elliptic Curve Diffie-Hellman
    Encryption, MAC: AES128-GCM (Gallois Counter Mode) AES128-GMAC

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Use standard format for subject name in permissions and identity

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

    The example permissions file has subject name as:

    <subject_name>/C=US/ST=CA/L=Sunnyvale/O=ACME Inc./OU=CTO Office/CN=DDS Shapes Demo/emailAddress=cto@acme.com</subject_name>
    

    This uses the non-standard notation "/" to separate fields whereas in the X.509 certificates it will be "," this will fore a normalization to compare the subject names.

    It would be better to change that format in the XML so it also uses ","

  • Reported: DDS-Security 1.0b1 — Fri, 12 Feb 2016 02:37 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change Certificate Subject Name element separator from "|" to ","

    Perform modifications shown in revised text section.

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Use standard format for subject name in permissions and identity

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

    The example permissions file has subject name as:

    <subject_name>/C=US/ST=CA/L=Sunnyvale/O=ACME Inc./OU=CTO Office/CN=DDS Shapes Demo/emailAddress=cto@acme.com</subject_name>
    

    This uses the non-standard notation "/" to separate fields whereas in the X.509 certificates it will be "," this will fore a normalization to compare the subject names.

    It would be better to change that format in the XML so it also uses ","

  • Reported: DDS-Security 1.0b1 — Fri, 12 Feb 2016 02:38 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change subject name delimiter from "/" to ","

    Do as requested in issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

(meta)data_protection_kind takes incorrect values

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

    Section 9.4.1.2.5.5 says:
    "This element may take the binary values TRUE or FALSE"
    This is wrong, it should say: "The metadata protection kind element may take three possible values: NONE, SIGN, or ENCRYPT".

    Likewise it says:
    "EndpointSecurityAttributes shall be set to the binary value specified in the “data protection kind" element"

    This is wrong, it should say: "EndpointSecurityAttributes shall be set to FALSE if the value specified in the “metadata protection kind" element is NONE and shall be set to TRUE otherwise".

    Similar issues occur in section 9.4.1.2.5.6.

  • Reported: DDS-Security 1.0b1 — Tue, 29 Dec 2015 22:23 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix (meta)data_protection_kind description

    Apply changes suggested in issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

The example governance does not validate with the governance XSD

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

    The Example machine readable file example_governance.xml has two problems:
    (1) Inside the <domain_rule> it uses an the element name "allow_unauthenticated_participants" whereas the Governance XSD calls this element "allow_unauthenticated_join"

    (2) The governance document specifies the DomainRule as <xs:sequence> of various elements. These forces the elements to appear always in that exact order. The example puts the elements inside the <domain_rule> in a different order

    The (1) should be corrected in the example_governance.xml file. The element name "allow_unauthenticated_join" appears in the spec in several places and it seems simpler to retain it rather than change it. Although it does make it somewhat inconsistent with the name used in the ParticipantSecurityAttributes.

    Either reorder the elements in the example_governance.xml inside<domain_rule> or else change the dds_security_governance.xsd to use <xs:all> as this construct allows the elements to appear in any order and still preserves the constraint that each element can appear at most once.

  • Reported: DDS-Security 1.0b1 — Sun, 3 Jan 2016 19:33 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Make Governance consistent with example and Attribute naming

    Modify governance to make it consistent with naming of ParticipantSecurityAttributes and the example governance document: allow_unauthenticated_join -> allow_unauthenticated_participants

    Also address issue http://issues.omg.org/browse/DDSSEC_-135 by using xs:boolean instead of BooleanKind
    And the suggested change to the schema for <domains> that appeared in the comments to http://issues.omg.org/browse/DDSSEC_-131 but could not be done there because 131 was already closed.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Use of 'TopicExpression' in Domain Governance

  • Legacy Issue Number: 19874
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    The Domain Governance schema defines a 'TopicExpression' as same as 'string' (simple inheritance). Why not use the 'string' type directly instead?
    Also the description in 9.4.1.2.5.1 says it is a set of topic names but does not say how we specify such a set. This is better defined in later sections such as 9.4.1.3.2.3.1.2. I suggest to add the description of topic name expressions from 9.4.1.3.2.3.1.2 to 9.4.1.2.5.1, as it is more precise:

    "The Topic name expression syntax and
    matching shall use the syntax and rules of the POSIX fnmatch() function as specified in POSIX 1003.2-1992, Section B.6 [38]"

  • Reported: DDS-Security 1.0b1 — Tue, 5 Jan 2016 05:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Add description of TopicExpression to 9.4.1.2.5.1

    See issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Useless BooleanKind in Domain Governance Schema


Typo - KxKeyCookie/KxCookie and KxMacCookie/KxMacKeyCookie

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

    In 9.5.2.1.2, the formula to compute KxKey and KxMacKey use the terms KxCookie and KxMacCookie, whereas the table 42 just below uses the terms KxKeyCookie and KxMacKeyCookie. They are the same thing, therefore names should be aligned.

    Regards,
    Cyril

  • Reported: DDS-Security 1.0b1 — Wed, 27 Jan 2016 16:22 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Addressed already by DDSSEC-14

    Addressed already by DDSSEC-14

  • Updated: Tue, 12 Jul 2016 14:45 GMT

adjusted_participant_key renamed to effective_participant_key without notice

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

    In 8.3.2.9.3, the validate_remote_identity method is defined to have an out parameter called adjusted_participant_key. In the built-in implementation (Authentication plugin) of this method, this parameter is no longer mentioned, or it is but with a different name: effective_participant_key. Are these both the same thing?
    If they are, then the spec should use the same name in both places .

    Regards,
    Cyril

  • Reported: DDS-Security 1.0b1 — Wed, 27 Jan 2016 16:13 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Rename effective_participant_key to be adjusted_particpant_key *

    Rename effective_participant_key to be adjusted_particpant_key

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typo CryptoTranformIdentifier instead of CryptoTranSformIdentifier

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

    CryptoTransformIdentifier is mispelled CryptoTranformIdentifier ('s' is missing) in various locations:

    • 8.5.1.5 - title of Table 20
    • 9.5.2.3 - transform_id type in SecureDataHeader
    • 9.5.3.3.1 - table 46 - in description of decode_rtps_message and preprocess_secure_submsg and decode_serialized_data
  • Reported: DDS-Security 1.0b1 — Wed, 27 Jan 2016 15:57 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Replace Tranform with Transform

    See Issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Construction of HandshakeRequestMessage is unclear


In DomainGovernance, what is default behaviour if a domain+topic topic_rule is not found

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

    What happens if no topic_rule (governance) is found for the 'domain+topic' ?

    This impacts behavior of: get_endpoint_sec_attributes()

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:10 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Extend Governance doc to support default domain rules and explain what happens when no Domain or Topic rule matches

    Extend syntax for Domain Rule to accept domain expressions such that we can construct default domain rules.

    This can be done extending the content of the <domain_id> element to allow certain expressions (e.g. <domain_id>ALL</domain_id>) or to be ranges (e.g. <domain_id> 0-10 </domain_id>) or lists (e.g. <domain_id> 0,10,20 </domain_id>) or combinations (e.g. (<domain_id> 0-5, 10, 20-40 </domain_id>).

    Explain that rules are applied in the same order they appear in the governance document and the first one that matches is "selected"

    Explain that if no Domain or Topic rule is found then the operation under consideration should give a "permissions error"

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Contents of KeyMaterial_AES_CTR_HMAC structure unclear

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

    How are the 'master salt', 'master session_salt' and 'master hmac_salt' values conveyed in the KeyMaterial_AES_CTR_HMAC data? Need a more complete description of the structure members.

    Also, recommend renaming/adding OctetSeq members to make it more clear:

    typedef long MasterKeyIdType;
    
    Structure members of the DDS::Security::KeyMaterial_AES_CTR_HMAC
        @Extensibility(EXTENSIBLE_EXTENSIBILITY)
        struct KeyMaterial_AES_CTR_HMAC {
          CipherKind        cipher_kind;
          HashKind          hash_kind;
          MasterKeyIdType   master_key_id;
          OctetSeq      master_key;
          OctetSeq      master_salt;         /* here */
          OctetSeq      master_session_salt; /* here */
          OctetSeq      master_hmac_salt;    /* here */
        }; 
    
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:22 GMT
  • Disposition: Closed; No Change — DDS-Security 1.0
  • Disposition Summary:

    With resolution of Issue14 this is no longer an issue

    With resolution of Issue14 this is no longer an issue

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In DomainParticipant permissions XSD: minOccurs of in

  • Legacy Issue Number: 19880
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In XSD for the DomainParticipant permissions document, the "Rule" complexType has a sequence of "publish" element with minOccurs="1".
    I don't see any reason to forbid a Rule with no "publish" element (e.g. a Grant with an allow_rule only allowing subscriptions).

    The minOccurs for the sequence of "publish" element should be "0".

  • Reported: DDS-Security 1.0b1 — Tue, 12 Jan 2016 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Merge into DDSSEC-134

    This issue is merged into DDSSEC-134 because that one is already modifying the Permissions XSD

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Parameters of get_endpoint_sec_attributes

  • Key: DDSSEC_-36
  • Legacy Issue Number: 19812
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §8.4.2.7.23 doesn't describe the parameters of the get_endpoint_sec_attributes operation.

    Moreover, in Table 18, only a PermissionHandle is specified as in parameter for this operation. As specified in §8.4.2.4 the PermissionHandle is associated to a DomainParticipant.

    But, according to §8.4.2.7.23, the get_endpoint_sec_attributes operation shall return the information related to the endpoint (DDS DataReader or DDS DataWriter). Thus, this operation miss some parameter(s) to indicate this endpoint.

  • Reported: DDS-Security 1.0b1 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Split get_endpoint_sec_attributes() into two: get_reader_sec_attributes() and get_writer_sec_attributes() also add parameters for Topic, partitions, and DataTags

    The get_endpoint_sec_attributes() needs additional information to determine the name of the Topic, the Partitions, and the DataTags. The Topic name is already needed to implement the logic of the builtin plugins. The others are expected to be needed for future standard plugins or those implemented by vendors or users.

    Likewise the get_endpoint_sec_attributes() needs to distinguish whether the Endpoint is a DataReader or DataWriter. One of the suggested approaches to this was to split it into two methods: get_reader_sec_attributes() and get_writer_sec_attributes(). This seems the cleanest and it is aligned with other plugin operations which already have separate methods for datareaders and datawriters.

    This change impacts Table 18 (AccessControl Interface). It renames get_endpoint_sec_attributes to get_datarwriter_sec_attributes and adds a row for get_datareader_sec_attributes

    It renames 8.4.2.7.23 (Operation: get_endpoint_sec_attributes) to Operation: get_datarwriter_sec_attributes

    It adds 8.4.2.7.24 Operation: get_datareader_sec_attributes

    It modifies the rest of the document replacing get_endpoint_sec_attributes with either get_datarwriter_sec_attributes or get_datareader_sec_attributes. Also clarifies better the use of these operations.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Parameters of get_participant_sec_attributes

  • Key: DDSSEC_-34
  • Legacy Issue Number: 19809
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §8.4.2.7.22 doesn't describe the parameters of the get_participant_sec_attributes operation.

  • Reported: DDS-Security 1.0b1 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Add more description of get_participant_sec_attributes

    Add a description of the parameters to get_participant_sec_attributes to section 8.4.2.7.22 (Operation: get_participant_sec_attributes)

    Add an entry to section 9.4.3, Table 40 (Actions undertaken by the operations of the bulitin AccessControl plugin) that describes get_participant_sec_attributes

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Authentication plugin: RSA or DSA ?

  • Key: DDSSEC_-33
  • Legacy Issue Number: 19800
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In Table 28 (p.152) it seems the Builtin Authentication plugin should accept RSA or DSA.
    But in §9.3 it's specified that the DomainParticipant must be configured with RSA material only (2048-bit RSA public key of the CA and the 2048-bit RSA public and private keys of the DomainParticipant)

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Addressed by DDSSEC-146

    This issue is addressed by DDSSEC_-146

  • Updated: Tue, 12 Jul 2016 14:45 GMT

PermissionsCredential in validate_local_permissions

  • Key: DDSSEC_-27
  • Legacy Issue Number: 19792
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.4.2.7.1 the PermissionsCredential parameter passed to the validate_local_permissions operation is described as following:
    "The nature of the credential is specific to each AccessControl plugin implementation."

    In §8.4.2.1:
    "The specific content of the PermissionsCredential shall be defined by each AccessControl plugin specialization and it may not be used by some AccessControl plugin specializations. The interpretation of the contents as well as the mechanism used to pass it to the AccessControl plugin shall be specified by each plugin implementation."

    In §9.4.2.1:
    "The DDS:Access:PKI-Signed-XML-Permissions plugin shall set the attributes of the PermissionsCredential objects as specified in the table below"

    So it seems it's up to the AccessControl plugin to create the PermissionsCredential (it's the only one to know how to set/interprate the attributes).

    Nevertheless, the middleware is supposed to pass the PermissionsCredential to the validate_local_permissions operation. But it has no way to create or get this PermissionsCredential object.

    We suggest to replace this PermissionsCredential parameter with the DomainId and the QoS Policies of the DomainParticipant to validate. Thus, the AccessControl plugin has a way to make distinction between 2 local DomainParticipant to validate their permissions, and can internally create different credentials.

  • Reported: DDS-Security 1.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Merged into DDSSEC_-14

    This issue was resolved by DDSSEC_14

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Plugins per-process or per-participant ?

  • Key: DDSSEC_-29
  • Legacy Issue Number: 19794
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The full §8 doesn't specify if the DDS middleware shall instantiate the plugins once per-process or once per-local-Participant.
    The plugins operations suggest 1 plugin per-process (see Autentication operations where the local Participant's identity is always passed as a parameter. Or the Access Control operations where the local Participant's permissions_handle is always passed as a parameter.)

    But in §9.4 it is specified that "Each DomainParticipant has an associated instance of the DDS:Access:PKI-Signed-XMLPermissions plugin". It is not specified for the other builtin plugins.

    The §8.1 should clearly states that the decision to instantiate 1 plugin per-process or 1 plugin per-participant is implementation dependant. And the §9.4 should not specify that "each DomainParticipant has an associated instance of the DDS:Access:PKI-Signed-XMLPermissions plugin", as it is possible to implement this plugin with 1 instance per-process only.

  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Specify plugins are instantiated per DomainParticipant

    In section 8.1 add a subsection that specified plugins are instantiated per DomainParticipant. Also state that the way the plugins are configured and bound to the DomainParticipant is implementation-specific

    Clarify that validate_local_identity, validate_local_permissions, and check_create_participant are called prior to the DomainParticipant being enabled.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Default permissions for partitions are too broad

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

    In section 9.4.1.3.2.3.1.2 (Publish Section) in the second to last paragraph it says:

    If there is no <partitions> Section then the rule allows publishing on any partition.

    Similarly in section 9.4.1.3.2.3.1.3 (Subscribe Section) in the second to last paragraph it also says:

    If there is no <partitions> Section then the rule allows subscribing on any partition.

    This seems to give too broad default permissions for 'allow rules' which can result on users incorrectly allowing what they did not intend.
    It is considered best-practices for allow rules to require explicit listing of what is allowed and default to not allow what not explicitly stated.

    Therefore it is suggested that the following changes are made.


    In section 9.4.1.3.2.3.1.2 (Publish Section) in the second to last paragraph replace

    If there is no <partitions> section then the rule allows publishing on any partition.
    With:
    If there is no <partitions> section then the rule allows publishing only in the "empty string" partition. See PARTITION QosPolicy entry in Qos Policies table of section 2.2.3 (Supported Qos) of the DDS Specification version 1.4.


    In section 9.4.1.3.2.3.1.3 (Subscribe Section) in the second to last paragraph replace:

    If there is no <partitions> section then the rule allows subscribing on any partition.
    With:

    If there is no <partitions> section then the rule allows subscribing only in the "empty string" partition. See PARTITION QosPolicy entry in Qos Policies table of section 2.2.3 (Supported Qos) of the DDS Specification version 1.4 .

  • Reported: DDS-Security 1.0b1 — Sun, 27 Dec 2015 15:29 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify 9.4.1.3.2.3.1.2 and 9.4.1.3.2.3.1.3 specify that if no partitions are specified permissions are limited to the empty partition

    As noted in the issue description it is safer for the allow behavior to default to narrower permissions. For this reason the changes suggested in the issue description should be applied.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Useless BooleanKind in Domain Governance Schema

  • Legacy Issue Number: 19876
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    The schema defines a new type for booleans: BooleanKind. However, XML schema standard already has a builtin 'boolean' type. Why not use it?

  • Reported: DDS-Security 1.0b1 — Tue, 5 Jan 2016 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Merged to DDSSEC_130

    Merging with DDSSEC_130 because they both affect the Governance XSD

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Inadequate XML type for 'domainId' in schemas


Wrong reference to "create_local_datawriter_crypto_tokens" and "create_local_datareader_crypto_tokens" in §8.8.6.3

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

    In section §8.8.6.3
    In says

    the DDS middleware shall call the operation create_local_datawriter_crypto_tokens on the KeyFactory to obtain the DatawriterCryptoHandle for the builtin DataWriter.

    However create_local_datawriter_crypto_tokens does not return DatawriterCryptoHandle and moreover according section 8.5.1.7.3 (Operation: register_local_datawriter) the operation that creates the DatawriterCryptoHandle is register_local_datawriter

    In section §8.8.6.3
    In says

    the DDS middleware shall call the operation create_local_datareader_crypto_tokens on the KeyFactory to obtain the DatareaderCryptoHandle for the corresponding builtin DataReader.

    However create_local_datareader_crypto_tokens does not return DatareaderCryptoHandle and moreover according section 8.5.1.7.5 (Operation: register_local_datareader) the operation that creates the DatareaderCryptoHandle is register_local_datareader.

    Likewise in §8.8.6.3 the reference to create_local_datawriter_crypto_tokens should be changed to register_local_datawriter and the reference to create_local_datareader_crypto_tokens" to "register_local_datareader".


    For these reason the following changes should be made:

    In section §8.8.6.3 change "create_local_datawriter_crypto_tokens" to "register_local_datawriter"

    In section §8.8.6.3 change "create_local_datareader_crypto_tokens" to "register_local_datareader"

    n section §8.8.6.4 (Item 1 in first list of items) change "create_local_datawriter_crypto_tokens" to "register_local_datawriter"

    In section §8.8.6.4 (Item 1 on second list of items) change "create_local_datareader_crypto_tokens" to "register_local_datareader"

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:24 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix reference to "create_local_datawriter_crypto_tokens" and "create_local_datareader_crypto_tokens" in §8.8.6.3

    Analysis in issue description is correct. Apply suggested corrections.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typos in DDS-Security Specification (2)

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


    The following typos in the spec should be fixed by applying the changes below

    In Section 9.4.1.2.5 Change "applies to apply" to "applies".

    In Table 44 Change "that can the" to "that the". (3 times)

    In Table 46 Change "receiving_articipant" to "receiving_participant".
    In Table 46 Change "with and" to "with an". (6 times)
    In Table 46 Change "transformation_id it that" to "transformation_id that". (2 times)

    In Section 9.5.3.3.4 Change "plain text the" to "plain text using the".

    In Section 9.6 Change "folowing" to "following".
    In Section 9.6 Change "means implies" to "states"
    In Table 48 Change "configurtion" to "configuration".
    In Section 10.1 Change "Entensibility" to "Extensibility".
    In Section 10.2 Change "In this rules" to "In these rules".

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 04:54 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix typos

    Fix the typos in issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Inconsistent naming "SingleSubmsgFlag", "SingleSubmessageFlag" versus "MultiSubmsgFlag"

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

    The spec uses the three names: "SingleSubmsgFlag", "SingleSubmessageFlag" and "MultiSubmsgFlag" to refer to the same concept.

    We would recommended that the name "MultiSubmsgFlag" is the one used as it appears 16 times in the spec whereas the other forms only appear 3 times each.

  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 21:52 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Replace SingleSubmsgFlag and SingleSubmessageFlag with MultiSubmsgFlag *

    Replace SingleSubmsgFlag and SingleSubmessageFlag with MultiSubmsgFlag throughout the specification.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Wrong reference to check_create_datareader in §9.4.1.2.5.4

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

    In §9.4.1.2.5.4 it says:

    If the value of “enable_write_access_control” element is TRUE, the operation
    check_create_datareader shall return a value according to what is specified in the Permissions document, see 9.4.1.3.

    This is incorrect, the write-access control setting should impact the creation of a DataWriter, not a DataReader.


    Corrective action:
    In §9.4.1.2.5.4 change the aforementioned sentence as shown below

    If the value of “enable_write_access_control” element is TRUE, the operation
    check_create_datawriter check_create_datareader shall return a value according to what is specified in the Permissions document, see 9.4.1.3.

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:39 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix reference to check_create_datareader in §9.4.1.2.5.4

    Analysis in issue description is correct. Apply suggested changes.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Wrong reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5

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

    In section §9.4.1.2.4.5 it says:

    The liveliness protection element specifies the protection kind (see 9.4.1.2.1) used for builtin DataWriter and DataReader associated with the ParticipantMessageSecure builtin Topic (see 7.4.2): BuiltinParticipantMessageSecureWriter and BuiltinParticipantMessageSecureWriter.

    This is incorrect the two endpoints associated with the ParticipantMessageSecure builtin Topic are BuiltinParticipantMessageSecureWriter and BuiltinParticipantMessageSecureReader .


    Action: In Section §9.4.1.2.4.5 change the aforementioned sentence as shown below:

    (see 7.4.2): BuiltinParticipantMessageSecureWriter and BuiltinParticipantMessageSecureReader BuiltinParticipantMessageSecureWriter.

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:32 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5

    Analysis in issue description is correct. Apply suggested changes.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Size of NONCE (Challenge_A/Challenge_B) in Authentication handshake messages undefined

  • Legacy Issue Number: 19864
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    The total size of the NONCE in binary_value1 of HandshakeRequestMessageToken and HandshakeReplyMessageToken (9.3.2.3.1) is undefined. The spec just says: "first 10 octets are set to match the ascii encoding of the string "CHALLENGE:"). There does not seem to be any mandatory size from a functional perspective, bu the spec should at least recommend a minimal size or refer to some recommendation on that.

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *9.3.2.3.1 and 9.3.2.3.2. Specify NONCE must include at least 32 characters and not be predictable *

    Specify that the NONCE in sections 9.3.2.3.1 and 9.3.2.3.2 must contain 32 characters in addition to the specified prefix.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

How to determine if creating a DomainParticipant is allowed

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

    The DomainParticipant Permissions document does not specifically indicate if we are allowed to create a participant in a domain. It indicates which topics are allowed/denied to publish/subscribe/relay. What specifically determines whether we are or are not allowed to create a participant?

    Is it simply the presence of a matching 'subject_name' entry?

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 13:59 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Table 40 adding detail on the conditions for the access control operations to succeed based on the governance and permissions documents

    Add more detailed information to Table 40 (Actions undertaken by the operations of the bulitin AccessControl plugin) in Section 9.4.3.

    Describe the precise behavior of the access-control operations for the built-in access control plugin based on the Governance and Permissions documents. Specifically the following aspects should be covered:

    • Impact of the existence of Topics in the Governance document that have enable_read_access_control or enable_write_access_control set to FALSE
    • Impact of the Publisher/Subscriber partition
    • Impact of DataReader/DataWriter Tags

    The description of the following operations in Table 40 should be updated with to include the behavior under the aforementioned circumstances:
    check_create_participant, check_create_datawriter, check_create_datareader, check_create_topic, check_local_datawriter_register_instance, check_local_datawriter_dispose_instance, check_remote_participant, check_remote_datawriter, check_remote_datareader, check_remote_topic

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Use of 'partition' in access control is unclear

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

    The mechanism of testing the 'partition' for match is not fully described. A “rule” specifies a set of partition names, and an “entity” provides a set of partition names.

    What is sufficient to determine that a match exists: exact set match, set intersection, strict subset match?

    This impacts the behavior of these methods on AccessControl:
    check_create_datareader()
    check_create_datawriter()
    check_remote_datareader()
    check_remote_datawriter()

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 13:57 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Permissions Document Schema to clarify rules for multiple partitions and topics

    Modify the XSD for the Permissions document so that each "grant" (publish/subscribe) contains three sections: <topics>, <partitions>, and <data_tags>.

    The <data_tags> remains as before.
    The <topics> section contains a list of topic expressions, each enclosed by the <topic> tag.
    The <partitions> section contains a list of partition expressions, each enclosed by the <partition> tag.

    For the grant to match there shall be a match of the topics, partitions, and data-tags criteria. This is interpreted as an AND of each of the criteria. For a specific criteria to match (e.g. <topics>) it is enough that one of the topic expressions listed matches (i.e. an OR of the expressions with the <topics> section).

    This change applies to the Permissions XSD as well as the Example Permissions files which appear both inside the specification and as separate machine readable documents.

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Is there implicit handling for builtin secure endpoints in the access control plugin?

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

    Should there be 'implicit' governance rules for the builtin secure endpoints? OR, must they be listed (or defaulted) in DomainGovernance just like any other topic?

    This impacts the behavior of:
    get_endpoint_sec_attributes()

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:04 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Fully specify the behavior of the AccessControl plugin for the builtin endpoints *

    The objective is to clarify the use of the AccessControl Plugin when creating/matching the builtin secure endpoints .
    The behavior of the Crypto plugin relative to the builtin secure endpoints seems reasonably clear so there is not need to add extra material on this one.

    Propose to add two new sections 8.8.3 (DDS Entities impacted by the AccessControl operations) and 8.8.4 (AccessControl behavior with local participant creation) to clarify this (see Specific Changes below).

    Add a Properties (sec 7.2.1) member to EndpointSecurityAttributes. Specify those are included in the ones passed to the CryptoFactory operations register_local_datawriter and register_local_datareader

    For symmetry so that this is also extensible add a Properties member to ParticipantSecurityAttributes. Specify those are are included in the ones passed to the CryptoFactory operation register_local_participant.

    The spec is inconsistent in that sometimes it uses "Properties" and others "PropertySeq". Also to be consistent with the DDS PIM naming of types the name should be changed from "Property" to "Property_t". To correct this the following changes should be applied: Change the name from "Property" to "Property_t" from "BinaryProperty" to "BinaryProperty_t" from "Properties" to "PropertySeq" and from "BinaryProperties" to "BinaryPropertySeq"

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Builtin Access Control plugin doesn't set is_rtps_protected

  • Key: DDSSEC_-35
  • Legacy Issue Number: 19811
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §9.4.1.2.4 specifies how to set 2 of the ParticipantSecurityAttributes members: allow_unauthenticated_participants and is_access_protected.
    But it doesn't specify how to set the is_rtps_protected member.

  • Reported: DDS-Security 1.0b1 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct errors in 9.4.1.2.4.6 and explain how is_rtps_protected is set

    The text in §9.4.1.2.4.6 wrongly says: "The liveliness protection element specifies.." when it should say "The RTPS protection element specifies ..." Similarly it wrongly says "The discovery protection kind element may take ..." where it should say "The RTPS protection kind element may take ..."

    The ParticipantSecurityAttributes attribute is_rtps_protected should be set to TRUE if the <rtps_protection_kind> element ( §9.4.1.2.4.6) is set to anything other than NONE.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Which encryption algorithm for the SharedSecret ?

  • Key: DDSSEC_-32
  • Legacy Issue Number: 19799
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In Table 33 the binary_value1 of the HandshakeFinalMessageToken is described as following:
    "Shall be set to the result of encrypting the SharedSecret with the Public Key of the remote DomainParticipant that is the destination of the HandshakeFinalMessageToken."

    The encryption algorithm to use is not specified. It should be to ensure interoperability between different implementations of this builtin plugin

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Specification of Encryption Algorithm for shared secret mentioned in Table 33

    The encryption algorithm for "Encrypting with a Public Key" is implied by the technology used for creating the Public/Private key pairs.
    In the case of Table 33 it is already specified in Section 9.3 that the Private/Public Key technology used is RSA with 2048-bit keys. However there is indeed an under-specification in that the padding used needs to be also specified.

    This issue of the need to specify the padding was also raised in DDSSEC_-38. Therefore issue DDSSEC_-32 is merged with DDSSEC_-38.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Table 18: check_remote_datawriter() should have a subscriber_partition parameter

  • Key: DDSSEC_-7
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    As specified in §8.4.2.7.10, the check_remote_datawriter() operation has a subscriber_partition parameter.
    It should appear in the table 18.

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:15 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Make Table 18 consistent with 8.4.2.7.10 and 8.4.2.57.11

    There several inconsistencies between table 18 and the definition on the corresponding section. The complete list is:

    For check_remote_datawriter:
    On Table 18 it takes an extra domain_id vs §8.4.2.7.10
    On §8.4.2.7.10 there is an extra subscriber_partition missing on Table 18
    On §8.4.2.7.10 there is an extra subscription_data_tag missing on Table 18

    For check_remote_datareader
    On Table 18 it takes an extra domain_id vs §8.4.2.7.11
    On §8.4.2.7.11 there is an extra publisher_partition missing on Table 18
    On §8.4.2.7.11 there is an extra publication_data_tag missing on Table 18

    In addition the operation check_local_datawriter_match operation needs access to the publisher_partition which is missing from Table 18 and §8.4.2.7.13. Similarly the operation check_local_datareader_match needs access to the subscriber_partition which is missing from Table 18 and §8.4.2.7.14.

    These inconsistencies need to be resolved so that both locations shown the same set of parameters and the check_local_datawriter_match and check_local_datareader_match get the parameters they need.

    The resolution is to preserve the parameters shown in Table 18 and adjust §8.4.2.7.10 and §8.4.2.7.11 to match Table 18 and add the missing parameters to check_local_datawriter_match and check_local_datareader_match.

    This means:

    On §8.4.2.7.10:

    • add domain_id parameter
    • remove subscriber_partition parameter
    • remove subscription_data_tag parameter

    On §8.4.2.7.11:

    • add domain_id parameter
    • remove publisher_partition parameter
    • remove publication_data_tag parameter

    On Table 18 and §8.4.2.7.13 add extra parameter publisher_partition to operation check_local_datawriter_match
    On Table 18 and §8.4.2.7.14 add extra parameter subscriber_partition to operation check_local_datareader_match

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Announcement of the new secure builtin endpoints

  • Key: DDSSEC_-5
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The chapter 7.3.7.1 specifies the EnityIds of the secure builtin endpoints.
    But the way a Participant announce those builtin endpoints are available is not specified, as it is for the DDSI builtin endpoints (see DDSI specification §8.5.3.2: availableBuiltinEndpoints attribute).
    This should be specified in this chapter.

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:54 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Add specification of how the added buitin endpoints appear in the ParticipantBuiltinTopicData *

    Section 7.4.1.3 (Extension to RTPS Standard DCPSParticipants Builtin Topic) should get additional text to describe how the presence of the new builtin endpoints is encoded within the ParticipantBuiltinTopicData.

    The encoding reuses the existing availableBuiltinEndpoints bitmap which is already used to describe the presence of the discovery builtin endpoints. To describe the presence of the new endpoints we define new bits that encode to the presence of the corresponding endpoint

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Handle types are shared by some plugins

  • Key: DDSSEC_-18
  • Legacy Issue Number: 19781
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §9.5.2: "All “Handle” types are local opaque handles that are only understood by the local plugin object that creates them"
    should be re-phrased as:
    "All “Handle” types are local opaque handles that are only understood by the local plugin objects that create or use them"

    For instance: the SharedSecretHandle is created by Authentication plugin but is also used by the Cryptographic plugin to encode Tokens (§8.3.2.7). This handle can't be opaque to the Cryptographic plugin as it needs the material it contains to encode Tokens (see §9.5.2.1.2 where the un-encrypted value of the SharedSecret is required).

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct description of Handle types on 9.5.2

    Make the change suggested in the issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In register_matched_remote_datareader() relay_out parameter should be IN

  • Key: DDSSEC_-1
  • Legacy Issue Number: 19752
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In chapter 8.4.2.7.11:
    "the relay_only parameter shall be remembered by the DDS middleware and passed to the register_matched_remote_datareader operation on the CryptoKeyFactory."

    To be consistent with this, the register_matched_remote_datareader() operation described in chapter 8.5.1.7.4 must have its relay_only parameter described as IN parameter.

  • Reported: DDS-Security 1.0b1 — Wed, 22 Apr 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *In section 8.5.1.7.4 (register_matched_remote_datareader) change relay_only to be an input parameter *

    As stated in the issue description section 8.5.1.7.4 (Operation: register_matched_remote_datareader) should change the parameter "relay_only" to be an input parameter. Currently it is an output parameter.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Errors in §8.8.6.4

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


    The following indicates typographical and wording errors in the spec that should be corrected as described below:


    In section §8.8.6.4 "register_matched_remote_datawriter" should be "register_matched_remote_datareader" in the the sentence:

    "For each non-builtin DataWriter...
    2. Call the operation register_matched_remote_datawriter for each discovered
    DataReader that matches the DataWriter."


    In section §8.8.6.4 Item numbered 2. after the sentence "For each non-builtin DataReader..." should be modified as shown below:

    2. Call the operation register_matched_remote_datawriter for each discovered
    DataWriter DataReader that matches the DataReader DataWriter.

  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:45 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix erors in §8.8.6.4

    Fix erors in §8.8.6.4 listed in issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Errors in 8.8.5.2 step 6, step 7, and step 11

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


    The following indicates typographical and wording errors in the spec that should be corrected as described below:

    In §8.8.5.2. Step 6 after Figure 26.
    In the sentence:

    "DataWriter1 shall not call any operations on the AccessControl plugin and shall to match DataWriter2 subject to the matching criteria specified in the DDS and DDS-XTypes specifications."

    "shall to" should be "shall" and "DataWriter2" should be "DataReader2".

    In §8.8.5.2. Step 7 after Figure 26 and Step 11 after Figure 27
    In the sentence:

    "DataReader1 shall operate according to the DDS and DDS-RTPS specifications without any calls to the AccessControl plugin."

    "DataReader1" should be "DataWriter1"

  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:36 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct errors in Errors in 8.8.5.2 step 6, step 7, and step 11

    Errors in 8.8.5.2 step 6, step 7, and step 11

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typos in DDS-Security Specification

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


    The following typos in the spec should be fixed by applying the changes below

    §2.2.2 Change "middeware" to "middleware".
    §7.4.1.1 Change "since could" to "since it could".
    §7.4.1.2 Change "called using"to "called".
    §7.4.3.1 Change "there are not" to "there are no".
    §7.4.4.2 Change "associated with associated with" to "associated with".

    §7.4.4.6.2, §7.4.4.6.3 Change "that what" to "that".
    Table 11: Logging and DataTagging rows need periods at the end of sentences.

    §8.3.1 Change "to detects" to "to detect".
    §8.3.1 Change "materal in support" to "material in support of".
    §8.3.2.3 Change "and send over" to "and sent over".

    §8.3.2.8 Change "supports the establish" to "supports establishing".
    Table 14 Change "GMCLASID_SECURITY_AUTH_HANDSHAKE" to "GMCLASSID_SECURITY_AUTH_HANDSHAKE".

    §8.3.2.9.5 Change "validate_remote_identity returns VALIDATION_PENDING_HANDSHAKE_REQUEST" to "validate_remote_identity returning VALIDATION_PENDING_HANDSHAKE_REQUEST".

    §8.3.2.9.15 Change "begin_hadshake_request" to "begin_handshake_request".

    §8.3.2.10 Change "the AuthenticationListener shall call the AuthenticationListener" to "the AuthenticationPlugin shall call the AuthenticationListener".

    Table 16 Change "DomainParticiapant" to "DomainParticipant".

    Table 17 Change "access is_access_protected" to "is_access_protected".

    Table 17 Change

    "If is_discoverye_protected is TRUE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsSecureWriter SEDPbuiltinPublicationsSecureReader. If is_discoverye_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsSecureWriter"

    to

    "If is_discovery_protected is TRUE then discovery information for
    that entity shall be sent using the SEDPbuiltinPublicationsSecureWriter or SEDPbuiltinSubscriptionsSecureWriter. If is_discovery_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsWriter".

    Table 17 Change

    "If is_discoverye_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsSecureWriter."

    to

    "If is_discovery_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsWriter."

    Table 17 Change "entitity" to "entity".

    §8.4.2.7.14, §8.8.8.4 Change "datarwriter" to "datawriter".
    §8.4.2.7.18 Change "pemissions" to "permissions".

    Table 21 Change "submesage" to "submessage".
    Table 22 Change "local_datawritert_crypto_handle" to "local_datawriter_crypto_handle".

    §8.5.1.9.5 Change "SubmessagesMsg" to "Submessages".

    §8.5.1.9.6 Change

    "If the re returned SecureSubmessageCategory_t equals INFO_SUBMESSAGE, then the DDS Implementation proceed normally to process the submessage without further decoding"

    to

    "If the returned SecureSubmessageCategory_t equals INFO_SUBMESSAGE, then the
    DDS Implementation proceeds normally to process the submessage without further decoding".

    §8.5.1.9.6 Change "retuned" to "returned" (3 times).
    Table 34 Change "retuned" to "returned" (1 time).

    The following sections have operation names with typos that should all be changed to "preprocess_secure_submsg":

    §8.5.1.9.7 (preprecess_secure_submessage, prepreprocess_secure_submessage, prepreprocess_secure_submsg)

    §8.5.1.9.8 (preprecess_secure_submessage, prepreprocess_secure_subessage, prepreprocess_secure_submessage)

    §8.5.1.9.9 Change "key us available" to "key is available".

    §8.5.1.9.9 Change "receving_reader_crypto" to "receiving_reader_crypto".

    §8.8.1, §8.8.3, §8.8.4 Change
    "DomainParticpant" to "DomainParticipant".

    §8.8.1 "shall validates" should be "shall validate".

    §8.8.1 Change "get_psrticipant_sec_attributes" to "get_participant_sec_attributes".

    The following sentences in §8.8.2.2 have too periods at the end. Remove one of them:

    "The operation returns PENDING_HANDSHAKE_REQUEST indicating further handshake messages are needed and Participant1 should initiate the handshake. ."

    "The operation returns PENDING_HANDSHAKE_MESSAGE indicating authentication is not complete and the returned messageToken1 needs to be sent to Participant2 and a reply should be expected.."

    §8.8.2.2 Change "determines this is message originated" to "determines that this message originated". (appears 2 times)

    §8.8.2.2 Change "Participamt1" to "Participant1".

    §8.8.3 Change "DCPSSecureSubscritions" to "DCPSSecureSubscriptions".

    8.8.5.2 Change "Partcipant" to "Participant" (3 times)

    8.8.7.2 and 8.8.7.3 Change "Partcipant" to "Participant".

    Table 5. Change "ENTITYID_ SEDP_BUILTIN_ SUBSCRITIONS_SECURE_READER to "ENTITYID_ SEDP_BUILTIN_ SUBSCRIPTIONS_SECURE_READER"

    §8.8.6.1 Change "Crytpo" to "Crypto". (2 times)

    In the Figures 28-30 Legend Change "KeyExchanage" to "KeyExchange".

    After Figure 31 (item 8) and Figure 33 (item 7), there are occurrences of "encounters parses". It should be changed to "parses".

    After Figure 32 (first paragraph), "that on the" should be "that the".

    §9.3.2.3: Change "HandshakeReplyMessgeToken" to "HandshakeReplyMessageToken". Change "PersimissionsCredential" to "PermissionsCredential"

    On the caption of Table 34, Table 40, Table 44, Table 45, Table 46, Table 48
    Change "bultin" to "builtin".

    Table 34:
    Change "DomainPartipant" to "DomainParticipant".
    Change "shall identical" to "shall be identical".
    Change "referece" to "reference".
    Change "requied" to "required".
    Change "conditon" to "condition".

    Change "und" to "and" in the sentences:

    process_handshake: "If the handshake_message_in does not contain the aforementioned property or the verification fails, then the operation shall fail und return ValidationResult_Fail."

    begin_handshake_reply: " If the handshake_message_in does not contain the aforementioned property or the verification fails then the operation shall fail und return ValidationResult_Fail."

    begin_handshake_reply: "If this verification fails the operation shall fail und return ValidationResult_Fail."

    Table 34: (on process_handshake on a handshake_handle created by begin_handshake_request)
    Change "cryptographycally" to "cryptographically".
    Change "hansdhake" to "handshake".

    Table 34 Change "stablished" to "established" in the sentence

    get_shared_secret: "The operation shall return a SharedSecretHandle that is internally associated with the SharedSecret stablished as part of the handshake."

    §9.4.1.2 Change "a discovered DomainParticipants" to "a discovered DomainParticipant".

    §9.4.1.2.1 Change "encode_rtps message" to "encode_rtps_message".

  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:31 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix typos in specification

    Apply the suggested fixes

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Replace encode_serialized_data with encode_serialized_payload


§8.8.7.1, §8.8.7.2, §8.8.7.3: "received by the BuiltinParticipantVolatileMessageSecureWriter" should be "received by the BuiltinParticipantVolatileMessageSecureReader"

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

    In sections §8.8.7.1, §8.8.7.2, §8.8.7.3 it says that BuiltinParticipantVolatileMessageSecureWriter receives messages. This is wrong it is the BuiltinParticipantVolatileMessageSecureReader the one that receives messages.

    To correct this following changes should be made:

    In sections §8.8.7.1, §8.8.7.2, §8.8.7.3 the sentence:

    "received by the BuiltinParticipantVolatileMessageSecureWriter"

    this sentence should be replaced with:

    "received by the BuiltinParticipantVolatileMessageSecureReader"

  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:52 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Replace "received by the BuiltinParticipantVolatileMessageSecureWriter" with "received by the BuiltinParticipantVolatileMessageSecureReader"

    Apply changes in issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

9.4.1.2.5 Governance Document description typo

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

    XML Governance Document:
    9.4.1.2.5: Currently reads:

    This element is delimited by the XML element <topic_rules> and appears within the domain ruleSection.

    It should read:

    This element is delimited by the XML element <topic_rule> and appears within the domain ruleSection.

    Note <topic_rule> vs <topic_rules>

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:34 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change <topic_rules> to <topic_rule> in 9.4.1.2.5

    Fix the typo as requested in the issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Data type for CryptoTransformIdentifier.transformation_kind_id is unclear

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

    The 'transformation_kind_id' field (aka transformationKind) is specified as octet[4] in one place (Table 20) and as 'long' in another place (7.3.7.2). This will cause misinterpretation of the data in the case of differing endian's.

    @Extensibility(FINAL_EXTENSIBILITY)
    struct CryptoTransformIdentifier {
      long        transformation_kind_id;  /* spec also says: transformationKind    octet[4] */
      OctetArray8 transformation_key_id;
    };
    
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:28 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change type of transformationKind in Section 7.3.7.2 from long to octet[4]

    In the IDL definition of struct CryptoTransformIdentifier that appears in Section 7.3.7.2 change the type of the attribute transformationKind from long to octet[4]

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Do the encode operations prefix the CDR data with a CDR encapsulation header?

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

    Do the encode operations (encode_serialized_data(), encode_datawriter_submessage(), encode_datareader_submessage(), encode_rtps_message()) produce a CDR encapsulation header in front of the CDR bytes of EncodeOperationOutputData?

    Recommend clarify the presence of the CDR encapsulation header.

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:26 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change SerializedData to SerializedPayload

    "SerializedData" is not an RTPS submessage element. The correct name for the RTPS submessage element is "SerializedPayload" (RTPS version 2.2, section 9.4.2.12). So the specification should replace the references to "SerializedData" with "SerializedPayload".

    This affects: 7.3.1, 7.3.2, 7.3.4, 7.3.5, 8.5.1.3, 8.5.1.9.1, 8.5.1.9.9, 8.8.8, 8.8.8.1, 8.8.8.4, 9.4.1.2.1,

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Parameters to register_matched_remote_datareader() inconsistent between spec and IDL.

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

    Spec indicates that register_matched_remote_datareader() accepts a parameter named “remote_participant_permissions”. The IDL spec for this operation does not include this parameter. Which one is correct?

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:25 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 8.5.1.7.4 Remove parameter remote_participant_permissions

    The operation register_matched_remote_datareader should not take the parameter remote_participant_permissions.

    This parameter does not appear in the IDL. It also does not appear in the parallel operation register_matched_remote_datawriter.

    For these reasons the paramater register_matched_remote_datareader should be removed from Section 8.5.1.7.4

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Description of HandshakeReplyMessage has an error

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

    Handshake Reply description, says same as Request message, "except that they correspond to the DomainParticipant that is sending the HandshakeRequestMessageToken."

    I think that should read {{

    {"... sending the HandshakeReplyMessageToken."}

    }

  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:16 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct section 9.3.2.3.2, Table 32

    Apply correction suggested in issue description.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Section 8.3.2.9.1 (Authentication plugin interface) should not be under 8.3.2.9 (Unauthenticated DomainParticipant entities)

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

    The section 8.3.2.9.1 "Authentication plugin interface" should not be nested under "Unauthenticated DomainParticipant entities". Rather it should be parallel section.
    The subsections 8.3.2.9.2 "Type: ValidationResult_t" to 8.3.2.9.17 "Operation: return_sharedsecret_handle" should be subsections of Authentication plugin interface".

    Suggested change:
    Change Section 8.3.2.9.1 (Authentication plugin interface) to be section 8.3.2.10. Then current section 8.3.2.10 (AuthenticationListener) becomes Section 8.3.2.11.

    The current subsections 8.3.2.9.2 "Type: ValidationResult_t" to 8.3.2.9.17 "Operation: return_sharedsecret_handle". Should become subsections of the new 8.3.2.10 (Authentication plugin interface) and take numbers 8.3.2.10.1 (for "Type: ValidationResult_t") to 8.3.2.10.16 (for "Operation: return_sharedsecret_handle").

  • Reported: DDS-Security 1.0b1 — Mon, 16 Nov 2015 08:19 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change Section 8.3.2.9.1 (Authentication plugin interface) to be section 8.3.2.10.

    Make the changes suggested in the issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

The padding used when encrypting the shared secret is not specified

  • Key: DDSSEC_-38
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    RTI's secure DDS implementation uses RSA_PKCS1_OAEP_PADDING to encrypt the shared secret during the handshake process, but this is not present in the specification.

  • Reported: DDS-Security 1.0b1 — Mon, 28 Sep 2015 06:09 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    On section 9.3.4 specify the padding used when using the PublicKey to encrypt something.

    Modify Table 36 in section 9.3.4.1 to specify that the operation Encrypt(PubK, data) should use EME-OAEP padding as defined in PKCS #1 v2.0 with SHA-1, MGF1 and an empty encoding parameter.

    Note: This corresponds to using the RSA_PKCS1_OAEP_PADDING option when calling RSA_public_encrypt() on the OpenSSL library.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Confusion between is_access_protected and allow_unauthenticated_participants

  • Key: DDSSEC_-11
  • Legacy Issue Number: 19774
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    This chapter describes the behavior when a DomainParticipant discovers a remote DomainParticipant which lack the ability to authenticate.
    According to §8.4.2.5, the is_access_protected attribute applies only "with a remote DomainParticipant that has successfully authenticated". And the allow_unauthenticated_participants attribute "indicates whether the DomainParticipant shall only match discovered DomainParticipants that Authenticate successfully".

    Therefore, the §8.8.2.1 and §8.8.2.2 should rather describe behavior when the value of allow_unauthenticated_participants is TRUE or FALSE, instead of the value of is_access_protected.

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct table 16, section 8.8.2.1 and 8.8.2.2

    The description of Table 16 Member allow_unauthenticated_participants and is_access_protected should be written to make it clear that:
    (1) allow_unauthenticated_participants determines whether remote DomainParticipant entities that cannot Authenticate are immediately rejected by the authentication process or allowed as "unauthenticated" entities.

    (2) is_access_protected determines whether the AccessControl plugin is called to check authorization for the remote DomainParticipant entities that are not disqualified by the authentication stage (this may include entities that were classified as unauthenticated).

    Also as indicated in the issue description sections 8.8.2.1 and 8.8.2.2 shall be corrected. In the places it says "-is_access_protected" it should say "allow_unauthenticated_access"

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Matching of ParticipantStatelessMessage builtin endpoints

  • Key: DDSSEC_-10
  • Legacy Issue Number: 19773
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In §8.8.2.2:
    "Discovered DomainParticipant entities that do implement the DDS Security specification, declare compatible Security Plugins and pass the Authentication protocol successfully shall be matched and the DomainParticipant shall also match ALL the builtin endpoints of the discovered DomainParticipant."

    Prior to Authentication protocol success, the ParticipantStatelessMessage builtin endpoints should have been matched for the handshake protocol to occur. The above sentence suggests the matching of those builtin endpoints only occurs after Authentication succeed, which cannot happen without this matching.

    The sentence could be rephrased as following:
    "Discovered DomainParticipant entities that do implement the DDS Security specification, declare compatible Security Plugins and pass the Authentication protocol successfully shall be matched and the DomainParticipant shall also match all the builtin endpoints of the discovered DomainParticipant, except the ParticipantStatelessMessage builtin endpoints which are matched prior to the Authentication protocol."

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Edit section 8.8.2.2 to clarify that ParticipantStatelessMessage is matched prior to authentication.

    Make changes described in Revised Text.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Figure 12: preprocess_rtps_submessage() should be preprocess_secure_submsg()


Replace "BuiltinParticipantStatelessMessager" with "state-machine"

  • Key: DDSSEC_-3
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In 8.3.2.8.1:

    2. Any time the state-machine indicates that a message shall be sent using the BuiltinParticipantStatelessMessageWriter and a reply message needs to be received by the BuiltinParticipantStatelessMessageReader, the DDS implementation shall cache the message that was sent and set a timer. If a correct reply message is not received when the timer expires, the BuiltinParticipantStatelessMessager shall send the same message again. This process shall be repeated multiple times until a correct message is received.

    This BuiltinParticipantStatelessMessager was never introduced before. I think it refers to the "state-machine". If so, the term should be replaced with "state-machine":

    ... If a correct reply message is not received when the timer expires, the state-machine shall send the same message again. ...

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 10:01 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:
    • Replace "BuiltinParticipantStatelessMessager" with "state-machine" in section 8.3.2.8.1*

    Apply suggested correction

  • Updated: Tue, 12 Jul 2016 14:45 GMT

The adjusted_participant_key must be a valid Participant GUID

  • Key: DDSSEC_-4
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.3.2.9.3 (validate_local_identity), in the description of the adjusted_participant_key parameter, it's worth to specify that this BuiltinTopicKey_t must be a valid Participant GUID to conform with the DDSI specification (§8.2.4.2): i.e. with ENTITYID_PARTICIPANT.

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:34 GMT
  • Disposition: Closed; No Change — DDS-Security 1.0
  • Disposition Summary:

    It does not seem the place of the security plugins to check GUID correctness

    See comments on issue proposal.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Table 1 and Table 2: the "name" attribute should be renamed as "key"

  • Key: DDSSEC_-6
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §7.2.1.1 the IDL definition of Property type has 2 attributes: "key" and "value". The table 1 just above should reflect this definition, renaming the "name" attribute as "key".

    The same apply to the Table 2 to reflect the IDL definition in §7.2.2.1.

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:22 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Make IDL in 7.2.1.1 consistent with Table 1 and IDL in 7.2.2.1 consistent with Table 2

    Change the IDL in Section 7.2.1.1 and in Section 7.2.2.1. In both cases change the attribute "string key;" to "string name;"

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Table 18: check_create_topic should not have a "property" parameter

  • Key: DDSSEC_-9
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.4.2.7.6, the specification of the check_create_topic() doesn't have a "property" parameter.
    This parameter should be removed from the table 18.

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:17 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Remove "Parameter property" from Table 18 check_create_topic

    Remove "Parameter property" from Table 18 check_create_topic

  • Updated: Tue, 12 Jul 2016 14:45 GMT

register_matched_remote_datawriter: wrong parameter name

  • Key: DDSSEC_-19
  • Legacy Issue Number: 19782
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    According to Table 22 (p.94) the register_matched_remote_datawriter has a "local_datareader_crypto_handle" parameter.

    Consequently, in §8.5.1.7.6, the following text:
    "Parameter local_datawriter_crypto_handle: A DatawriterCryptoHandle returned by a prior call to register_local_datawriter. If this argument is nil, the operation returns nil."

    must be replaced by this:
    "Parameter local_datareader_crypto_handle: A DatareaderCryptoHandle returned by a prior
    call to register_local_datareader. If this argument is nil, the operation returns nil."

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 8.5.1.7.6 change local_datawriter_crypto_handle to local_datareader_crypto_handle

    Make the change suggested in issue description.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Content of initialization_vector and hmac_key_id

  • Key: DDSSEC_-31
  • Legacy Issue Number: 19790
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The KeyMaterial_AES_CTR_HMAC is specified with 2 members named initialization_vector and hmac_key_id.
    But it's not clearly specified how those members are used and what should be their content.

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Content of initialization_vector and hmac_key_id

    Section 9.5.2.1.1 just defines the data types. The way to use it and how these fields are filled is defined in section 9.5.3.3

    Combine with DDSSEC_78

  • Updated: Tue, 12 Jul 2016 14:45 GMT

New callback for authentication failures

  • Key: DDSSEC_-30
  • Legacy Issue Number: 19795
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    When a DomainParticipant tries to authenticate itself with a remote DomainParticipant but is rejected by this one, there is no way for the user of this DomainParticipant to know it has been rejected (unless a potential security log).

    We could add an operation to the DDS::DomainParticipantListener (or to an inheriting class) to do such a callback:
    on_remote_authentication_failure(BuiltinParticipantKey_t remote_participant_key)
    which will be called each time the DomainParticipant is rejected by a remote DomainParticipant.

  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Closed; No Change — DDS-Security 1.0
  • Disposition Summary:

    New callback for authentication rejection

    In general it is considered best-practice to not communicate on the network authentication failures, nor provide the reasons for it. In addition the suggested enhancement would require an extra message which increases the surface of a DOS attack.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Benefit of session keys: wrong sentence

  • Key: DDSSEC_-23
  • Legacy Issue Number: 19787
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The following sentence has a wrong syntax (missing or extra words?) and should be re-phrased for clarification:
    "This has the benefit that the ‘session’ keys used to secure the DATE STREAM DATA can be modified as needed to maintain the security IF THE STREAM WITHOUT HAVING to perform explicit rekey and key-exchange operations."

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 9.5.3.3.2 "Encode/decode operation virtual machine": correct grammar

    In section 9.5.3.3.2 first paragraph below below Table 47, correct the grammar of the sentence.

    It says "date stream data" instead of "data stream"
    It says "security if the stream" instead of "security of the stream"

  • Updated: Tue, 12 Jul 2016 14:45 GMT

How to find the MasterSessionSalt to decrypt ?

  • Key: DDSSEC_-26
  • Legacy Issue Number: 19791
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §9.5.3.3.5 explains how to find the MasterKey, the MasterSalt and the SessionId.
    Then it specifies:
    "The session_id attribute within the SecureDataHeader_AES_CTR_HMAC is used to obtain the proper SessionSalt and SessionKey. Note that this only requires a re-computation if it has changed from the previously received SessionId for that CryptographicSessionHandle."

    But a re-computation of the SessionSalt requires the MasterSessionSalt in combination with the MasterKey and the SessionId (see §9.5.3.3.3). And it's not specified how to find the MasterSessionSalt.

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *In Section 9.5.3.3.5 clarify how to locate the MasterSessionSalt *

    In section 9.5.3.3.5 clarify that the MasterSessionSalt is also located from the transformation_key_id.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typo in KeyMaterial_AES_CTR_HMAC: initilization_vector

  • Key: DDSSEC_-25
  • Legacy Issue Number: 19789
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In definition of the KeyMaterial_AES_CTR_HMAC struct:
    sequence<octet, 32> initilization_vector;
    should be replaced by
    sequence<octet, 32> initialization_vector;

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Section 9.5.2.1: Modify IDL for KeyMaterial_AES_CTR_HMAC *

    Perform change indicated in issue descritption

  • Updated: Tue, 12 Jul 2016 14:45 GMT

CipherKind and HashKind enums both use NONE

  • Key: DDSSEC_-24
  • Legacy Issue Number: 19788
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The IDL declarations of CipherKind and HashKind enums both contain the NONE member.
    This is not allowed in IDL as "Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that scope" (see CORBA 3.1 part 1 §7.20.2).

    We suggest to change the enums definitions as following:
    enum CipherKind

    { CIPHER_NONE = 0, CIPHER_AES128 = 1, CIPHER_AES256 = 2 }

    ;
    enum HashKind

    { HASH_NONE = 0, HASH_SHA1 = 1, HASH_SHA256 = 2 }

    ;

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 9.5.2.1: Modify IDL for CipherKind and HashKind

    Perform the change suggested in issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Meaning of MasterHMACSalt

  • Key: DDSSEC_-21
  • Legacy Issue Number: 19785
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In Table 47, the meaning of MasterHMACSalt is described as following:
    "A random vector used in connection with the MasterKey to create the SessionHashKey."

    But "SessionHashKey" is never specified and in §9.5.3.3.3 the MasterHMACSalt is used for the computation of the SessionHMACKey.

    Thus, the meaning shoud be rephrased as following:
    "A random vector used in connection with the MasterKey to create the SessionHMACKey."

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    In table 47 replace "SessionHashKey" with "SessionHMACKey"

    Change table 47 as stated in the issue description.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Extra parameter to register_local_datawriter

  • Key: DDSSEC_-20
  • Legacy Issue Number: 19784
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.5.1.7.3 the register_local_datawriter operation is specified with 4 parameters (local_participant_identity, participant_crypto, local_datawriter_properties, exception).

    But in Table 22 (p.93) it's specified with 3 parameters only (participant_crypto, local_datawriter_properties, exception). And the register_local_datareader is also specified with 3 parameters only (participant_crypto, local_datareader_properties, exception).

    Thus, the local_participant_identity parameter should be removed from §8.5.1.7.3.

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Remove parameter "local_participant_identity" from section 8.5.1.7.3 (Operation: register_local_datawriter)

    Perform the change suggested in the issue description

  • Updated: Tue, 12 Jul 2016 14:45 GMT

validate_remote_permissions cannot return TRUE

  • Key: DDSSEC_-13
  • Legacy Issue Number: 19776
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In description of is_access_protected attribute:
    "...and only match those for which the validate_remote_permissions operation returns TRUE."

    According to §8.4.2.7.2 this operation returns a PermissionHandle. The sentence should be rephrased as:
    "...and only match those for which the validate_remote_permissions operation doesn't returns HandleNIL."

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify table 16 description of validate_remote_permissions

    As requested in the issue description modify description to reflect the fact that validate_remote_permissions returns HandleNIL instead of FALSE on failure.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typo: is_discoverye_protected

  • Key: DDSSEC_-12
  • Legacy Issue Number: 19775
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In description of is_discovery_protected attribute, there is twice the same typo:
    is_discoverye_protected instead of is_discovery_protected

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix is_discoverye_protected typo in Table 17

    Replace is_discoverye_protected with is_discovery_protected in Table 17

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Value of HandshakeRequestMessageToken 1st property

  • Key: DDSSEC_-17
  • Legacy Issue Number: 19780
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In table 31, the "properties" attribute is specified with 2 properties. The first is described as:
    "A property with name set to “dds.sec.identity” and value set to string containing the elements of the value attribute of the IdentityCredential, one character per element. Note that the octets in the IdentityCredential value were defined to hold
    characters resulting from a PEM encoding ( 9.3.2.1) so the value of the property is precisely those characters."

    In §9.3.2.1 the IdentityCredential is defined with 2 "values" attribute: binary_value1 and binary_value2.
    Which one shall be used as property value for HandshakeRequestMessageToken ? binary_value1 I guess, but it should be specified.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Table 21 - Specify the use of the IdentityCredential binary_value1 in the properties

    Table 21 - "properties" row, "Attribute value" column. When describing the construction of the property name "dds.sec.identity" it mentions the use of the "value" attribute from the IdentityCredential. Instead of "value" it should say "binary_value1".

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Inconsistency between "BuiltinParticipantStateless" and "InterParticipantStateless"

  • Key: DDSSEC_-16
  • Legacy Issue Number: 19779
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    7.4.3 introduces the "ParticipantStatelessMessage builtin Topic" and the "BuiltinParticipantMessageWriter" and "BuiltinParticipantMessageReader".

    §8.3.2.8.1 specifies "the Authentication Handshake uses the BuiltinParticipantStatelessMessageWriter and BuiltinParticipantStatelessMessageReader endpoints".

    But in all §8.3.2.9 the words "InterParticipantStatelessMessage", "InterParticipantStatelessWriter", "InterParticipantStatelessReader" are used instead.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Subsections of 8.3.2.9 renaming InterParticipantStatelessWriter/Reader

    Subsections of 8.3.2.9 use the term InterParticipantStatelessWriter/Reader where they should use BuiltinParticipantMessageWriter/Reader instead.

    Subsections of 8.3.2.9 InterParticipantStatelessMessage where they should use ParticipantStatelessMessage instead.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Wrong bits indexes in effective_participant_key

  • Key: DDSSEC_-15
  • Legacy Issue Number: 19778
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In description of actions for validate_local_identity (Table 34), the returned effective_participant_key is described with following sentences:
    "... The following 48 bits (bits 48 to 96) shall be set to the first 48 bits of the SHA-256 hash of the candidate_participant_key.
    "The remaining 32 bits (bits 97 to 127) shall be set identical to the corresponding bits in the candidate_participant_key"

    The correct bits indexes should be "bits 48 to 95" and "bits 96 to 127".

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Table 34 validate_local_identity description of effective_participant_key

    Modify the description of the effective_participant_key as suggested in the issue description.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Complexity of Authentication Plugin Model

  • Key: DDSSEC_-28
  • Legacy Issue Number: 19793
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

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

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

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

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

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

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

  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    *Move authentication state machine to plugin implementation *

    This issue would may require a significant change to the Authentication Plugin API but does not affect interoperability and would not be observable to a regular end-user of a product that implements the specification.

    For these reasons the FTF decided it was best to defer it so that resources could be devoted to issues that affect interoperability of the experience the end user would have.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Meaning of SessionId

  • Key: DDSSEC_-22
  • Legacy Issue Number: 19786
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    in Table 47, the meaning of SessionId contains this sentence:
    "Knowledge of the MasterKey, MasterSalt, MasterHMACSalt, and the SessionId is sufficient to create the SessionKey, SessionSalt, and SessionHMACKey."

    This is not true, as the MasterSessionSalt is also required to create the SessionSalt (see §9.5.3.3.3).

    Thus, the sentence shoud be rephrased as following:
    "Knowledge of the MasterKey, MasterSalt, MasterSessionSalt, MasterHMACSalt, and the SessionId is sufficient to create the SessionKey, SessionSalt, and SessionHMACKey."

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Table 47. Improve description of sessionId

    Make the change specified in the issue description.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

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

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

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

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

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

  • Reported: DDS-Security 1.0b1 — Sun, 3 Jan 2016 17:42 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    Defer specification of crypto factory configuration to RTF

    Issue deferred to RTF. It does not affect interoperability, or even portability as long as vendors provide a way to configure it.
    In a future revision we can standardize the configuration mechanism if it seems worthwhile.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear

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

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

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

  • Reported: DDS-Security 1.0b1 — Sat, 21 Nov 2015 18:27 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    Clarify whether the whole RTPS message can be encrypted

    After discussing in the FTF we decided to close this one. It seems premature to force the restriction when it is something the user can configure. As we gather more user experience if this becomes an issue we can revisit it but for now it seems best to defer it.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Name of builtin topic is DCPSParticipantMessage not ParticipantMessage

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

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

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

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

  • Reported: DDS-Security 1.0b1 — Tue, 19 Jan 2016 01:39 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    Defer renaming to RTF

    Issue deferred to RTF because it is limited to the terminology used within the specification. It does not affect interoperability or portability.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Permissions XSD in section 9.4.1.3 and example in 9.4.1.4 are inconsistent with normative machine readable file

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

    The normative machine readable XSD file for the permissions document schema
    http://www.omg.org/spec/DDS-SECURITY/20160301/dds_security_permissions.xsd

    Is inconsistent with what is copied into section 9.4.3.1. The most glaring difference is that 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.

  • Reported: DDS-Security 1.0b1 — Fri, 25 Mar 2016 18:12 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 29 Mar 2016 15:35 GMT