The permission schema defines starting and end dates of validity as 'strings'. Why not use the XML schema standard built-in datatype for 'date' instead? It would be more appropriate.

Change the Permissions schema to use xs:dateTime

Replace use of xs:string with xs:dateTime in permissions schema
Apply also the change suggested in DDSSEC_-139 which was merged into this issue

In section 8.5.1.9.9, there is no mention of the inline_qos parameter.

In section 8.8.10.1 and 8.8.10.4 the method is referred to as decode_serialized_data (should be decode_serialized_payload).

Section 9.5.3.3.1, Table 56, last row, the method is referred to as decode_serialized_data (should be decode_serialized_payload). Also in this row, there is a mention of encode_serialized_data (should be encode_serialized_payload).

There various other "inconsistencies" that were introduced by some naming changes in the issues previusly reolved. They should be fixed as part of this issue as well. See comments to ths issue.

Perform the suggested typo fixes and and consolidation of the terms used

See issue description and comments

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"

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

In order to facilitate more consistent security logging, we can document a set of common error conditions that should be logged by the security implementation. This is a follow-on to DDSSEC_-37.

Duplicate resolution in DDSSEC_-147

This issue duplicates the same resolution entered in http://issues.omg.org/browse/DDSSEC_-147 and thus addresses DDSSEC_-37

This is because http://issues.omg.org/browse/DDSSEC_-165 was created as a clone of a http://issues.omg.org/browse/DDSSEC_-37

The reason is that DDSSEC_-37 does not show up in any of the listings... so this is a workround for that problem.

DDSSEC-14 introduced 3 new RTPS Submessage Elements:
SecureDataHeader, SecureDataBody, and SecureDataTag

It also introduced 3 new RTPS submessages: SecurePrefixSubMsg, SecureBodySubMsg, SecurePostfixSubMsg

These impact figures figures: 5, 6, 12-19,

New figures should be created and attached. This potentially also affects the UML model.

Update figures and XMI

Update figures and XMI with the ones attached

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)

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

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

Remove the spurious references to PermissionCredential

See issue description

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

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

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.

Enhance Authentication handshake

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

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.

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

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

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

Perform modifications shown in revised text section.

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

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

Do as requested in issue description

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.

Fix (meta)data_protection_kind description

Apply changes suggested in issue description

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.

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.

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

Add description of TopicExpression to 9.4.1.2.5.1

See issue description

The Domain Governance and permissions schema use type 'string' for domain_id. Considering that a domain ID is defined as 'long' in DDS IDL, the corresponding XML type should be 'int'. Please consider using XML schema 'int' type for domain_id.

Reference:
https://community.rti.com/best-practices/fully-define-your-dds-types-do-not-rely-opaque-bytes-or-other-custom-encapsulations

Duplicates DDSSEC_137

Issue closed as duplicate

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

Addressed already by DDSSEC-14

Addressed already by DDSSEC-14

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

*Rename effective_participant_key to be adjusted_particpant_key *

Rename effective_participant_key to be adjusted_particpant_key

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

Replace Tranform with Transform

See Issue description

HandshakeRequestMessage is defined to include two properties, but it is not clear where they should go in the structure: string_properties, or binary_properties?

Recommend:

credential → string_property[0]
permissions → binary_property[0]

*Merged with http://issues.omg.org/browse/DDSSEC_-14*

This issue addresses the same problem as http://issues.omg.org/browse/DDSSEC_-14 so it is merged with it.

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

This impacts behavior of: get_endpoint_sec_attributes()

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"

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 */
    }; 

With resolution of Issue14 this is no longer an issue

With resolution of Issue14 this is no longer an issue

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

Merge into DDSSEC-134

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

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.

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.

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

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

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)

Addressed by DDSSEC-146

This issue is addressed by DDSSEC_-146

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.

Merged into DDSSEC_-14

This issue was resolved by DDSSEC_14

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.

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.

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 .

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.

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

Merged to DDSSEC_130

Merging with DDSSEC_130 because they both affect the Governance XSD

The Domain Governance and permissions schema use type 'string' for domain_id. Considering that a domain ID is defined as 'long' in DDS IDL, the corresponding XML type should be 'int'. Please consider using XML schema 'int' type for domain_id.

Reference:
https://community.rti.com/best-practices/fully-define-your-dds-types-do-not-rely-opaque-bytes-or-other-custom-encapsulations

Resolved by DDSSEC_75

The resolution of DDSSEC_75 addresses this issue as well.

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"

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.

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

Fix typos

Fix the typos in issue description

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.

*Replace SingleSubmsgFlag and SingleSubmessageFlag with MultiSubmsgFlag *

Replace SingleSubmsgFlag and SingleSubmessageFlag with MultiSubmsgFlag throughout the specification.

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.

Fix reference to check_create_datareader in §9.4.1.2.5.4

Analysis in issue description is correct. Apply suggested changes.

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.

Correct reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5

Analysis in issue description is correct. Apply suggested changes.

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.

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

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?

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

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

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.

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

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

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.

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.

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

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.

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.

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

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.

*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

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

Correct description of Handle types on 9.5.2

Make the change suggested in the issue description

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.

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

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.

Fix erors in §8.8.6.4

Fix erors in §8.8.6.4 listed in issue description

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"

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

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

Fix typos in specification

Apply the suggested fixes

In view of http://issues.omg.org/browse/DDSSEC_-80 it would be clearer if the CryptoTransform operation encode_serialized_data was called encode_serialized_payload. And similarly the decode_serialized_data was renamed decode_serialized_payload

Rename encode_serialized_data and decode_serialized_data with encode_serialized_payload and decode_serialized_payload, respectively

Per the issue description rename the CryptoTransform operation encode_serialized_data to encode_serialized_payload

Also rename the CryptoTransform operation decode_serialized_data to decode_serialized_payload

This replacement shall occur both in the text and the figures. In addition Figures 13 and 20 still reference a RTPS submessage element called "SerializedData" per the resolution of DDSSEC-80 the correct name is "SerializedPayload". Therefore this changed figures 5, 7, 13, and 20 attached to this issue resolution should also have the "SerializedData" changed to "SerializedPayload".

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"

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

Apply changes in issue description

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>

Change <topic_rules> to <topic_rule> in 9.4.1.2.5

Fix the typo as requested in the issue description

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

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]

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.

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,

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?

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

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

}

Correct section 9.3.2.3.2, Table 32

Apply correction suggested in issue description.

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").

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

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.

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.

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.

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"

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

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

Make changes described in Revised Text.

In Figure 12, the CryptoTransform interface has a preprocess_rtps_submessage() operation.
But according to §8.5.1.9 (p.107) and §8.5.1.9.6 this operation should be named: preprocess_secure_submsg()

Change prepreprocess_rtps_submsg to prepreprocess_secure_submsg

In the UML model rename the CryptoTransform operation preprocess_rtps_submsg to be called preprocess_secure_submsg

This affects the UML model as well as the figures created from this model appearing as Figure 12, 31, 32, 33, and 34

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

• Replace "BuiltinParticipantStatelessMessager" with "state-machine" in section 8.3.2.8.1*

Apply suggested correction

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.

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

See comments on issue proposal.

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.

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

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.

Remove "Parameter property" from Table 18 check_create_topic

Remove "Parameter property" from Table 18 check_create_topic

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

Section 8.5.1.7.6 change local_datawriter_crypto_handle to local_datareader_crypto_handle

Make the change suggested in issue description.

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.

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

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.

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.

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

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"

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.

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

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

*Section 9.5.2.1: Modify IDL for KeyMaterial_AES_CTR_HMAC *

Perform change indicated in issue descritption

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

;
enum HashKind

;

Section 9.5.2.1: Modify IDL for CipherKind and HashKind

Perform the change suggested in issue description

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

In table 47 replace "SessionHashKey" with "SessionHMACKey"

Change table 47 as stated in the issue description.

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.

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

Perform the change suggested in the issue description

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

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.

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

Fix is_discoverye_protected typo in Table 17

Replace is_discoverye_protected with is_discovery_protected in Table 17

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.

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

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.

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.

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

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.

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.

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

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

Table 47. Improve description of sessionId

Make the change specified in the issue description.

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.

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.

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.

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.

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

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.

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.

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