There is an inherent DoS network amplification attack that exploits peer-to-peer discovery. See https://issues.omg.org/browse/DDSIRTP26-6

This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.

Provide a layer of PSK protection

Peovide the means to use a pre-shared secret to protect any RTPS message (e.g. bootstrap messges) that is not otherwise protected by the keys that the DomainParticipants exchange.

Also define the "pre-shared" key mechanism as a separate "builtin" plugin

When "performing authentication only," the encode_serialized_payload operation wraps the SerializedPayload inside CryptoHeader and CryptoFooter. This resulting byte stream takes the place of the original SerializedPayload submessage element in a Data(Frag) submessage.

On the receiving side, this modified submessage element is passed to decode_serialized_payload. The problem comes in parsing this CryptoHeader-SeralizedPayload-CryptoFooter group.

The CryptoHeader is of fixed size and only contains octet-width data (therefore has no padding), so parsing it and determining where SerializedPaylod starts is trivial.

Then the implementation needs to determine where SerializedPayload ends in order to determine which bytes to authenticate. There is no in-stream indication of where the SerializePayload ends.

One possibility would be to look at the end of the byte sequence that decode_serialized_payload received and "step backwards" by the length of the CryptoFooter, however the CryptoFooter is variable length (with receiver_specific_macs). Even if the implementation has external knowledge that receiver_specific_macs are not in use, the alignment requirement of the plugin_sec_tag.receiver_specific_macs.length effectively makes this a variable-length element (also see issue #58).

To resolve this, an additional element for "length" could be added before the SerializedPayload, just like the CryptoContent submessage element does. This would make parsing the encoded payload similar for the encrypt and auth-only cases.

Defer to next RTF

Defer to next RTF

The description of is_write_protected starts with "Indicates if read access". This should be "Indicates if write access."

Defer to next RTF

Defer to next RTF

domainId is not listed in section 8.4.2.9.12

Defer to next RTF

Defer to next RTF

In 9.5.3.3.4.2 remove this part:
"Note that the cipher operations have 16-byte block-size and add padding when needed. Therefore the secure data.length (“N”) will always be a multiple of 16."

AES-GCM doesn't add padding. The implication of this is that the CryptoContent Submessage Element may end at an arbitrary point in the stream (from the point of view of alignment). Bringing the stream "back into alignment" will depend on the usage context:

• When encoding payload, the CryptoFooter follows directly after CryptoContent. This means that CryptoFooter's first element (common_mac) may start unaligned. Then receiver_specific_macs.length appears in the stream as a 32-bit value so it will be preceded by 0-3 padding bytes depending on the length of CryptoContent.
• When encoding a submessage or full message, CryptoContent is followed by the start of another submessage which must be aligned to 4 per the RTPS spec.

Defer to next RTF

Defer to next RTF

9.5.3.3.6 "The message digest is computed on the crypto_header and the ciphertext."

This statement appears to contradict the descriptions of common_mac and receiver_specific_macs in 9.5.3.3.4.4 (payload), 9.5.3.3.4.5 (submessage), and 9.5.3.3.4.6 (message).

Defer to next RTF

Defer to next RTF

XML Schema doesn't use all-caps TRUE and FALSE.
https://www.w3.org/TR/xmlschema-2/#boolean

Defer to next RTF

Defer to next RTF

In the Table 70 row for register_local_datareader, the ReaderKeyMaterial is created based on Data Protection Kind. This should be Metadata Protection Kind because the ReaderKeyMaterial signs/encrypts submessages and not data payloads.

Defer to next RTF

Defer to next RTF

The term CryptoKeyTransform is used 3 times (section name of 9.5.3.3, text of 9.5.3.3.1, caption of Table 72). These should be CryptoTransform.

Defer to next RTF

Defer to next RTF

participant_security_attributes is currently spelled participant_security_atributes on page 25 of the specification.

Defer to next RTF

Defer to next RTF

Section 9.3.1.3 (Identity Certificate) indicates it is possible to use certificate chains.

However the language of this section is confusing because an X.509 v3 Certificate does not contain a chain. It is a single certificate. What can contain a chain of certificates is a file. E.g. the standard "PEM" file format referenced in Table 44 can contain a certificate chain.

To clarify this the following modifications are suggested:
(1) In table 44, row for "identity_certificate" change from:
"URI to a X509 certificate signed by the IdentityCA in PEM format"...
To
"URI to a X509 certificate (or certificate chain) signed by the IdentityCA, either as the root CA or as an intermediate CA, in PEM format"

(2) In section 9.3.1.3 change from:
"An X.509 v3 Certificate [39] that chains up to the Identity CA (see 9.3.1.1)."
To:
"A X.509 v3 Certificate chain [39] that is signed by the Identity CA (see 9.3.1.1) either as the root or as an intermediate CA in the chain"

(3) In section 9.3
In bullet 3. Clarify it may not be a single X.509 rather it can be a chain.

(4) In table 49, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

(5) In table 50, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

(5) In table 52, field "validate_local_identity" indicate this is not a single certificate but a certificate chain.

(6) In Table 53 IdentityCertificate is undefined. Maybe it should be "identity_certificate" and refer to the property defined in Table 44.

Defer to next RTF

Defer to next RTF

The behavior of the built-in CryptoKeyFactory operations is described in Table 70. Many entries of this table include direct references to details of the built-in Access Control plugin's configuration file (an example, "see 9.4.1.2.5.6").

It would be easier to follow and more modular if this was changed to instead reference the data structure that the CryptoKeyFactory can actually see, which in this case is ParticipantSecurityAttributes.

Defer to next RTF

Defer to next RTF

All the other flag names defined here take the form of "PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_XXX_YYY". Should the BUILTIN part of this flag really be there? I believe this should instead read: PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_DISCOVERY_ENCRYPTED.

Defer to next RTF

Defer to next RTF

Table 70 introduces the term "Participant2ParticipantKxKeyMaterial" which isn't used anywhere else in the spec.

It would be helpful to have a table that lists each "key material" object along with which operation creates it and how it's used.

Defer to next RTF

Defer to next RTF

The last paragraph of 9.5.3.3.4.3 refers to the "CryptoHeader", this should be "CryptoFooter"

Defer to next RTF

Defer to next RTF

Section 7.2.5 changes QoS in ways that break RTPS compatibility, however minor modifications can fix this.

Because the mapping for PropertyQosPolicy in Table 10 (is this an implied entry in Table 12 as well?) conflicts with RTPS's definition of PID 0x59, the Binary Property values may not be sent on the wire. Note that RTPS has no concept of appendable extensibility, and requires backwards compatibility for all 2.x versions.

We can represent this restriction on PropertyQosPolicy in IDL4:

@extensibility(FINAL)
struct PropertyQosPolicy {
  PropertySeq value;

  @non-serialized
  BinaryPropertySeq binary_value;
};

The practical effect of this change is that any BinaryProperty entry with propagate == TRUE is not actually propagated inside PropertyQosPolicy. However a search through the specification indicates that there is no requirement for this, at least for built-in plugins. Any other plugins are necessarily vendor specific so those are not necessarily restricted from using an appendable policy, as long as they are aware of the compatibility issues (for allow_unauthenticated_participants == TRUE).

Also, for consistency the Tag and DataTags structs could be made @extensibility(FINAL). This is not as important since only Security-aware implementations will know about DataTagQosPolicy.

Defer to next RTF

Defer to next RTF

There are a few cross-references that don't resolve, resulting in the text "see 0" or "in subclause 0" in the spec:

• Table 30 plugin_endpoint_attributes column 3 contains "found in 0"
• Table 52 get_authenticated_peer_credential_token contains "See section 0"
• 9.4.1.2.6.7 right before the bullet list
• Table 63 validate_remote_permissions
• 9.5.3.3.4.1 final paragraph has "subclause 0"

Defer to next RTF

Defer to next RTF

In the normative IDL, the struct ParticipantSecurityAttributes's field plugin_participant_attributes has type ParticipantSecurityAttributesMask but it should have type PluginParticipantSecurityAttributesMask

Defer to next RTF

Defer to next RTF

Section 7.4.4.2 "TopicSecurityAtributes" should be "Attributes"

Section 8.8.9.1, 8.8.9.2, and 8.8.9.3 "cripto" should be "crypto"

Section 8.8.3 "best-efforts" should be "best-effort"

Section 8.8.4 "simultanepusly" should be "simultaneously"

Table 63 caption: "bulitin" should be "built-in"

Section 9.5 "BEST_EFFORTS" should be "BEST_EFFORT"

Section 9.5.2.3 "indentifier" should be "identifier"

Section 9.5.3.1 "ciphetext' should be "ciphertext"

Normative IDL parameter 1 of create_local_data_crypto_tokens "cryto" should be "crypto"

Defer to next RTF

Defer to next RTF

Section 7.4.1.3 'Reserved RTPS parameter IDs' reserves the whole 0x1000 to 0x1FFF (plus 0x5000 to 0x5FFF for must-understand) . That is 2 x 4096 PIDs. In reality DDS security only uses 6 PIDs... So this is a bit too much of a land grab.

It would be better to be more conservative and reserve a smaller range which can then be expanded as needed.

RTPS version 2.4 states that the reserved range for DDS security is 0x1000 to 0x10FF and 0x5000 to 0x50FF.

Section 7.4.1.3 should be updated to reflect this reduced range.

Defer to next RTF

Defer to next RTF

In CryptoKeyFactory, all operations other than the unregister_* ones return handles. But the descriptions of register_matched_remote_participant and register_local_datawriter (8.5.1.7.2-3) end with "operation returns false". That should be "operation returns HandleNIL".

Defer to next RTF

Defer to next RTF

In Table 48 (9.3.2.4), "properties" should be "binary_properties" so that the property future_challenge is treated as binary, matching Table 49's challenge1.

Defer to next RTF

Defer to next RTF

DDS security does not provide any additional means to secure the DDS-RPC service calls. Absent this the protection would be based on the underlying DDS Topics.

DDS-RPC maps all operations of an interface to two unkeyed Topics. One for the request and one for the reply. The request Topic is used for all operations and likewise the reply Topic.

Thus relying on the underlying Topics would provide access control granularity at the level of the service and not allow to give narrower permissions. E.g. invoke certain operations and not others. This is not acceptable in some deployment situations.

One solution may be to make the Topics keyed by the operation. This is possible now that IDL42 allows the discriminator of a union to act as the key.

Alternatively DDS-Security could specify some other mechanism, for example designate a data-tag to indicate the operations that the request DataWriter may invoke. The receiver side would check that the operation invoked matches the DataWriter tag before processing the request.

Defer to next RTF

Defer to next RTF

In section 8.8.2.2, it's established that the BuiltinParticipantStatelessMessage built-in endpoints are used for exchanging the "authentication handshake" messages. This makes sense based on how those built-in endpoints are defined in 7.4.3 and how they're used in some parts of 8.3.2.9 and .11.

However there are parts of 8.3.2.11 and 8.8.2 that describe this handshake using the names BuiltinParticipantMessageWriter / Reader (note the absence of "Stateless"). The name BuiltinParticipantMessageWriter is defined by the RTPS spec as the endpoint used to implement the participant scoped liveliness (see RTPS 2.2 section 8.4.13.2).

Defer to next RTF

Defer to next RTF

If the crypto plugin transforms the payload but the layers containing the payload (submessage or message) are not transformed, the resulting Data/Frag submessage contains no indication that its payload has a nonstandard format.
Since this spec is essentially defining a new minor version of RTPS (along with RTPS RTF process concurrent to this), one of the reserved flags in the submessage header of Data/Frag can be defined as FLAG_S meaning that the format of the SerializedPayload submessage element is defined by the security spec.

Defer to next RTF

Defer to next RTF

9.4.1.2.6.4 describes Enable Read Access Control, however the bullet list within this section uses the xml tag <enable_write_access_control> (twice), it should be <enable_read_access_control>.

Defer to next RTF

Defer to next RTF

The rows in Table 61 is_submessage_encrypted and is_payload_encrypted each have paragraphs starting "If is_*_encrypted is FALSE..." and including "GCM authenticated encryption", which should be "GMAC authentication transformation" like the corresponding rows of Table 59.

Defer to next RTF

Defer to next RTF

In Table 30, the entry for is_payload_protected says "If is_payload_protected is FALSE, then the CryptoKeyFactory, KeyExchange and CryptoTransform operations are called only if is_payload_protected is TRUE", but the last phrase should be "only if is_submessage_protected is TRUE".

Defer to next RTF

Defer to next RTF

2nd parameter to get_topic_sec_attributes has type "String", should be "string".

Defer to next RTF

Defer to next RTF

The last paragraph of 7.4.2 indicates that TopicSecurityAttributes::is_liveliness_protected is used to determine if a liveliness message should be sent using the new DCPSParticipantMessageSecure builtin endpoint or the old DCPSParticipantMessage builtin endpoint.

However it is not clear which topic's TopicSecurityAttributes are to be used. The liveliness message essentially belongs to the participant and not any given topic (see RTPS v2.2 8.4.13.5). Should the security spec use ParticipantSecurityAttributes here instead?

Defer to next RTF

Defer to next RTF

Section 7.4.3.2:

The data type associated with these endpoints is ParticipantStatelessMessage defined
below (see also 7.2.5):
typedef ParticipantStatelessMessage ParticipantGenericMessage;

Two issues:
a. I don't see how this relates to 7.2.5, should that be 7.2.6?
b. The typedef is backwards. Typedef declares a new name (second) from an existing type (first).

Defer to next RTF

Defer to next RTF

SubscriptionBuiltinTopicDataSecure should inherit from SubscriptionBuiltinTopicData in the local module, not the one in the DDS:: module.

Defer to next RTF

Defer to next RTF

Operation: get_datarwriter_sec_attributes
should be
Operation: get_datawriter_sec_attributes

Defer to next RTF

Defer to next RTF

The permissions document allow and deny rules contain a section for matching the data tags of the DataReader/DataWriter. The match is based on an exact match of the tag-name and tag-value.

For consistency with the way we match the permissions for Topic and Partitions we should also allow an expression for the tag-value portion. This is only for the permission rule itself. Not for the DataTag QosPolicy.

So to match the rule the DataTag name in the Qos must exactly match the name in the permissions document (no expressions here) and the DataTag value in the Qos should match (using fnmatch) the expression in the permissions document.

Defer to next RTF

Defer to next RTF

Normative IDL has no parameter handshake_message_in (from Table 23). It would be possible to use handshake_message_out to serve the purposes of "in" since it's an inout parameter in IDL, but is that the intention here?

Defer to next RTF

Defer to next RTF

In the normative IDL interface CryptoTransform, the decode_datawriter_submessage operation uses the "in" parameter passing mode for SecurityException – should be "out" or "inout".

Defer to next RTF

Defer to next RTF

The normative IDL doesn't have SecureSubmessageCategory_t, but it does have SecureSumessageCategory_t which appears to be a typo.

Defer to next RTF

Defer to next RTF

Table 32 (8.4.2.9) has a topic_name parameter for both get_datawriter_sec_attributes and get_datareader_sec_attributes, however this parameter is not present in the normative IDL.

Defer to next RTF

Defer to next RTF

In the normative IDL, the type of the 2nd parameter for set_permissions_credential_and_token is listed as PermissionsCredential but should PermissionsCredentialToken.

Defer to next RTF

Defer to next RTF

DDS::Security::LongLongSeq is not used so it should be removed from the normative IDL.

Defer to next RTF

Defer to next RTF

The specification contains full copies of the machine readable XSD files:

• DDS Security Access Control Permissions XSD
• DDS Security Access Control Governance XSD

This causes problems as updates may not always be done consistently.

Therefore it would be better if the specification removed this duplication and just referenced the external machine-readable files.

Defer to next RTF

Defer to next RTF

The specification depends on many other standards that appear referenced thought the specification and in Annex A (References) but do not appear in Section 3.

Section 3 should be expanded to include the subset of those references that are used for normative behavior. [46], [47], and [52] are clear examples of references that should be moved to Section 3.

Defer to next RTF

Defer to next RTF

The UML diagrams in the specification use UML stereotypes, such as <<discovery>>. However these are not documented anywhere in the specification nor do they appear in the XMI.

Also the diagrams are non-standard UML in that they show superclasses in the top right corner. See for example Figure 10.

These issues should be corrected.

Defer to next RTF

Defer to next RTF

The authentication handshake requires participants to exchange their permission files. This is done as clear text.

Visibility into the permissions file leaks information as to what the system Topic names are as well as what the application publishes and subscribes. This can be sensitive for some systems.

Aside form this sending this document is potentially expensive as the knowledge could be available on a separate channel.

The RTF should look share this information only with authenticated participants and possibly also avoid sending it if it is already known to the peer participant.

Related this is the fact that permissions are "monolithic" of you need to add a permission to a Participant you need to create and sign a new document. Would be nice to have some way to grant/propagate incremental permissions. E.g. something that could be bundled into the propagation of the Endpoint discovery data itself.

Defer to next RTF

Defer to next RTF

The Security plugin model supports being able to control access to each DDS Topic instance (instead of just controlling access to the DDS Topic). However the builtin plugin permission files do not provide a way to configure these permissions.

This is important for many DDS-Security use-cases where each instance represents a different object and needs to separately indicate who has access to it. For example imaging a "CarPosition" topic that is used to publish the position of cars. Someone may be given permission to suscribe or publish its own car position, but not other cars. Likewise a manufactured or insurance company may be given permissions to the cars that they manage but not others.

Defer to next RTF

Defer to next RTF

At end of 2nd to last para document has (matching the errata):

"sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid."

It should probably be

"sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid set to zero.”

Defer to next RTF

Defer to next RTF

In 7.2.3.1, DataHolder is a struct annotated with @extensibility(APPENDABLE) and no optional fields.
However in ptc/17-09-26 (normative IDL), DataHolder has no @extensibility annotation and two optional fields.

Defer to next RTF

Defer to next RTF

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

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

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

Defer to next RTF

Defer to next RTF

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

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

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

Defer to next RTF

Defer to next RTF

There are some issues with the UML model that should be improved. This came from the AB review of the RTF 1 report:

● SubmessageKind should be an Enumeration not a Class. And it’s missing its Literals. Tables 4,5 indicate Literals would include SEC_BODY, SEC_PREFIX, SEC_POSTFIX, SRTPS_PREFIX, SRTPS_POSTFIX
● SubmessageFlag is totally underspecified but probably should not be a PrimitiveType
● Likewise CryptoState. In fact there are far too many PrimitiveTypes, none of them documented, which should probably be Strings.

Defer to next RTF

Defer to next RTF

The machine-readable files have comments that trace their changes to the Jira issues that caused them. This hurts the use of the specification so they should be removed.

Defer to next RTF

Defer to next RTF

The following two sections in DDS-Security 1.1 affect future versions of DDSI-RTPS.

The DDSI-RTPS should include language that makes sure future versions do not conflict with what DDS-Security and future revisions thereof may do.

Specifically the following two sections of DDS-Security 1.1 should be taken into consideration

7.3.6.1 Change to the RTPS minor version number
Implementations of this specification shall set the RTPS protocol version number present in the RTPS Header. The RTPS Major version number shall be set to 2 and the RTPS Minor version number shall be set to 3. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

7.4.1.3 Reserved RTPS parameter IDs
This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range:
0x1000 to 0x1FFF and 0x5000 to 0x5FFF. The second interval covers the same range of parametersID, except they have the must-understand bit set. This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

Defer to next RTF

Defer to next RTF

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.

Defer to next RTF

Defer to next RTF

The goal of this issues is to identify incorporate any additions that would allow systems built using DDS-Security to meet the CNSSP-15 security requirements.
https://imlive.s3.amazonaws.com/Federal%20Government/ID151830346965529215587195222610265670631/CNSSP15.pdf)

This is an important requirements for many systems and we are running into many users that are asking whether DDS-Security can be used to meet CNSSP-15 security requirements.

It seems like currently the "builtin plugins" are not enough because they do not include support for stronger asymmetric key algorithms. For example when using ECDSA digital signatures the minimal requirement is using 384-bit keys (e,g, NITS's Curve P-384). However the builtin plugins only include support for 256 bit EC keys.

Add support for additional crypto algorithms

Reorganize specification separating the definition of the crypto algorithms from its use by the plugins, such that, it becomes possible to extend the algorithms used, specifically adding support for algorithms that meet CNSSP-15 top-secret requoirements.

The builtin plugins create session keys for multiple DDS entities (DomainParticipant, DataWriter, DataReader) and share those with the matched Entities that successfully authenticate and have the proper authorization. The session key(s) are used to protect the messages sent by the entity using encryption and/or message-authentication codes.

Importantly the same key (e.g. a DataWriter key) may be shared with multiple matched DataReaders.

There are situations where an Entity may need to change is Session Key. E.g. if it has been used to encode too many messages, or if there is a need to "revoke" access for one or more existing matched Endpoints.

The specification should provide and describe the mechanism that implementations may use to change session Keys such that they are able to interoperate across vendors.

Add a mechanism to change session keys

Provide a mechanism to change session keys and send the modified keys to the authenticated authorized Participants

DomainTag was added to DDSI-RTPS as a mechanism to further identify/isolate DDS Domains beyond the separation provided by the DomainId. For two participants to be on the same domain both the DomainId and the DomainTag (a string) must match. The domain-tag string matching is literal (strcmp() character by character) there is no expressions.

Resulting from this it makes sense to add support for them to DDS security, without this support there would be no way to have different governance or permissions for domains that differ only on the DomainTag.

Adding support will impact the SPIs (e.g. extra parameters on validate_local_identity, validate_local_permissions, and most of thje check_operations. Operations that currently take the DomainId_t as a parameter should be expanded to also take a DomainTag.

Adding support will impact Governance and Permissions files.
E.g. the DomainIdSet should which is used on both files be expanded to incorporate domain tags.

Add specification of domainTag to governance and permissions

Extend governance and permissions documents to allow specifying the domain tags that identify the domain(s) to which the rules apply.

Starting with DDS-XTYPES version 1.2 a data type can be serialized using XCDR version 1 or version 2. This impacts the serialization of APPENDABLE and MUTABLE types. It does not impact the serialization of FINAL types unless they contain 8-byte primitives (long long or double) or optional members.

DDS-Security was written before DDS-XTYPES 1.2 came out. So all the products are using XCDR version 1.

Going forward DDS-Security should specify that it always uses XCDR version 1 for serialization of the types defined in the specification.

Be precise about the XCDR version used for serialization

Specify XCDR version f1 or serializing the data exchanged by DDS Security plugins.

Topic uses the DDS::Time_t which rolls over at 2038.
We should update to the newer definition to be adopted in DDS 1.6

We may need to use a different type name to allow both to co-exist
Curent definition is this:

extensibility(APPENDABLE) // After DDSSEC12-29
struct BuiltinLoggingType {
    octet  facility;  // Set to 0x0A (10). Indicates sec/auth msgs
    LoggingLevel severity;
    Time_t timestamp; // Since epoch 1970-01-01 00:00:00 +0000 (UTC)
    string hostname;  // IP host name of originator
    string hostip;    // IP address of originator
    string appname;   // Identify the device or application 
    string procid;    // Process name/ID for syslog system
    string msgid;     // Identify the type of message
    string message;   // Free-form message

    // Note that certain string keys (SD-IDs) are reserved by IANA
    map<string, NameValuePairSeq>  structured_data; 
};

Modify BuiltinLoggingType to use 64 bits to hold the timestamp seconds

Introduce a new Log topic that uses a 64-bit integer for the seconds.
Since this is defined as an "application-level" topic discovery and type matching will take care of interoperability with earlier versions of the specification.

Old topic name is deprecated but an implementation can support it for backwards compatibility.

The string literal "SessionKey" (and "SessionReceiverKey") is used without additional context as part of the binary input to HMAC. Add to this section that the ASCII encoding of "SessionKey" without a nul terminator is required.

Section 9.3.3.3.2 talks about a "bit array" type, clarify what that is.

Change "bit array" to "octet array" and clarify string concatenation in 9.5.3.3.3

Add clarification regarding how the strings are concatenated to create teh input to the HMAC256 functions

IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken are specified in Table 46, Table 47, Table 48 of the DDS Security 1.1 spec. as containing "properties".

This is inconsistent with the description of HandshakeRequestMessageToken, HandshakeReplyMessageToken, and HandshakeFinalMessageToken. These specify binary_property.

They should be consistent. In fact AuthRequestMessageToken specifies that the content of the property with key "future_challenge" should match what is sent in HandshakeRequestMessageToken "challenge1"

It appears vendors are all using binary_properties as they are all interoperating. Therefore Table 46, Table 47, Table 48 should be modified to say "binary_property' for the attribute name.

Modify attribute name in the tables for dentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken

Per the issue description, Attribute name "properties" in tables 46, 47, 48, defining IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken should be modified to "binary_properties"

XTypes defines 4 new built-in endpoints for its TypeLookup Service. DDS-Security should define secure versions of these, just like the secure versions of discovery built-in endpoints.

Secure TypeLookup Built-In Endpoints

Secure DDS deployments that make use of XTypes features including its TypeLookup Service must have a secure way of communicating TypeLookup information.

The HandshakeRequestMessageToken's dh1 property (Table 49) contains a Diffie-Hellman Public Key. The text of Table 49 says that this is encoded as a CDR Big Endian Serialization. However, the data type of the Public Key is neither a CDR Built-In type nor specified in IDL. Thus the encoding is underspecified.

Explain the encoding of diffie-hellman keys in the handshake tokens

Explain the encoding of public keys into octet sequences

The DDS Security version 1.1 specification mentions:

If the Participant Private Key is a RSA key, then:

The value of the c.dsign_algo property shall be “RSASSA-PSS-SHA256”.
The digital signature shall be computed using the RSASSA-PSS algorithm specified in PKCS #1 (IETF 3447) RSA Cryptography Specifications Version 2.1 [44], using SHA256 as hash function, and MGF1 with SHA256 (mgf1sha256) as mask generation function.
This RFC is the one aforementioned. It states:

This encoding method is parameterized by the choice of hash function, mask generation function, and salt length. These options should be fixed for a given RSA key, except that the salt length can be variable (see [31] for discussion). Suggested hash and mask generation functions are given in Appendix B.

In the appendix, we can see an example where the salt length is the same as the hash length:

RSASSA-PSS-params ::= SEQUENCE
Unknown macro:
Unknown macro:

However, the salt length doesn't have to be the hash length. The WolfSSL and OpenSSL crypto libraries support several options (Openssl doc here and WolfSSL doc here). Our current approach is to use OpenSSL's default option: "maximum permissible value" (pkcsBlockLen - hLen - 2) when signing and auto (detect salt length from the signature) when verifying.

proposed solution
The specification should mention the salt length used when generating the signature. Otherwise, it should say that auto must be used when verifying the signature. This would allow interoperability (WolfSSL for example doesn't use auto by default).

Specify how to configure the salt length for RSA digital signatures

Merging with DDSSEC12-90 because the section referenced in the issue description ( 9.3.2.5.2) no longer describes algorithm-specific details, rather the crypto algorithms description are in a new dedicated section under section 8 "Common Cryptographic Algorithms" . So it is simpler to handle adding this detail to Issue 90.

Section 8.2.1 Message Module says:

To provide a deterministic behavior and a deterministic message size, DataWriters associated with an TsnTalker in the Deployment configuration (see subclause 7.2.3.1) may need to limit their RTPS Message exchange to RTPS Messages that include the following RTPS Submessages:
• InfoTimestamp
• Data
• DataFrag

This should be expanded to include the RTPS HeaderExtension as well as GAP.

Later in the section there is an explanation of why GAP may not be needed:

RTPS Submessages responsible for achieving reliability or in-order delivery, such as Gap, AckNack, NackFrag; as well as the rest of Interpreter Submessages, may be sent as part of “Best Effort” Streams. However, given the guarantees of the underlying TSN system, this sort of traffic may be unnecessary for TSN-enabled DataReaders and DataWriters. Also, retransmissions and other types of aperiodic traffic may fail to meet the schedule and configuration of the TSN Streams associated with the delivery of time-critical data.

However GAP is not just for reliability or in-order delivery. It is also used in best-efforts in situation where a sample is not relevant to a reader (e.g. because of writer-side content filtering), even if the sample is sent best-efforts.
Gaps are needed to distinguish lost samples from samples that are intentionally-skipped. If the gap is not present, the reader side will interpret non sequential sequence numbers as sample loss, impacting status variables in in the DataReader.

This issue was entered in the wrong RTF

This issue was entered in the wrong RTF. Should have been entered in DDSTSN. Refiling there....

The specification does not address whether DDS-Security can be deployed on top of TSN.
The logical assumption would be yes, but then the use of the RTPS sub-messages introduced by DDS security (e.g. SRTPS_PREFIX) should be mentioned.

This issue was entered in the wrong RTF

This issue was entered in the wrong RTF. Should have been entered in DDSTSN. Refiling there....

In 9.4.1.3.2 Grant Section, the spec states:

"A permissions [sic, should be grant] Section with a subject name that does not match the subject name given in the corresponding Authorization certificate shall be ignored."

It is not clear what algorithm should be applied to determine if two subject_names "match"; and this has interoperability implications.

A 'simple' approach would be a simple string comparison.

A 'complex' approach would be to do the following:

1) parse each subject_name as a series of name=value pairs,
2) check that all name's exist in each subject_name
3) check that for each name, the corresponding 'value' matches, using regex (for example fnmatch(), or similar) processing.

The more complex approach might be beneficial, because it could support using a 'wildcard' Common Name. For example, in the permissions file, use a Subject Name like this:

      <subject_name>/C=US/ST=CO/O=Twin Oaks Computing/CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com</subject_name>

Then, the Identity Cert's could be constructed with a more specific Subject Name, like "CN=participant1.twinoakscomputing.com", and it would match.

Specify format of subject name and rules for comparison

The string format of the subject name should be specified. The proposal is to follow IETF RFC 4514 (https://datatracker.ietf.org/doc/html/rfc4514#section-3), that is a ","-separated sequence of <name>=<value> pairs. For example:

"C=US, ST=CO, O=Twin Oaks, Computing, CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com"

The matching of subject names should check the list of names is the same and the corresponding values match using the fnmatch() function (POSIX 1003.2-1992, Section B.6)

The order of the names does not impact the matching.

Note that "," may be present in the value part. Likely we do not want to constrain this as it is generated from tools like openssl which may put those commas based on user input.
However this can be unabiguously parsed making the following assumptions.

• The character '=' is reserved. it can only appear to separate the name v. value pair.
• Whitespace surrounding the "=" is ignored/removed for the purposes of comparison
• The name can;t have whitespace. and can;' have ","
• The value starts after the '=' skipping any whistapce that immediately follows the '=' abd ectends to the last "," before the next "="

The operations
check_create_participant
check_create_datawriter
check_create_datareader
check_remote_participant
check_remote_datawriter
check_remote_datareader
check_local_datawriter_match
check_local_datareader_match

Should be called when the Qos (or the discovery XXXBuiltinTopicData) change for the one of the involved entities.

This should be added to the proper 8.4.2.9.x sections.

Indicate that AccessControl operations called on a change of Qos

When the Qos of a local DDS Entity changes the corresponding operation on the Access Control that checks thet the Participant has the necessary permissions should be called.

When the Qos of a remote DDS Entity changes the corresponding operation on the Access Control that checks that the remote Participant has the necessary permissions should be called.

The check_create_participant entry of "Table 63 - Actions undertaken..." in the case where is_access_protected is true and all topic entries in Governance have enable_read_access_control and enable_write_access_control both true specifies that check_create_participant returns false. Thus the participant can't be created and this configuration won't be usable.

If the intent of enable_read/write_access_control is to defer to the Permissions document to determine both readability and write-ability of this participant (for the given topic) it would seem like this case should be supported and allowed by check_create_participant.

As part of resolving this issue we should also address DDSSEC12-85, meaning state whether a <default> clause should always be present.

Clarify interpretation of enable_read/write_access_control

Clarify behavior as suggested in issue description

In 7.3.5 (Immutability of Publisher Partition Qos in combination with non-volatile...)

The criteria (1) is not consistent with the goal stated at the end of the section about "prevents data that was published while the DataWriter had associated a set of Partitions from being sent to DataReaders that were not matching before the Partition change and match after the Partition is changed."

To accomplish this criteria (1) should be re-stated to say this impacts if the Topic associated with the DataWriter has TopicSecurityAttributes with is_read_protected set to TRUE.

*Change wording in 7.3.5 item (1) *

Modify wording in 7.3.5 "Immutability of Publisher Partition Qos in combination with non-volatile Durability kind" item (1)
to state that this applies if the the Topic has "is_read_protected" set to true.

In the definition of the various Handshake Tokens, certain property values are specified with literal strings in the spec (such as "RSASSA-PSA-SHA256"). Since these are inserted into binary_properties, the spec should describe the encoding: is there a length prefix (like CDR string?), is there a trailing nul (like CDR string?), assume the encoding is ASCII but it would be good to specify this.

Merge with DDSSEC12-90

DDSSEC12-90 is already making similar clarifications and adds the following explanation to 7.3.3.1:

When setting the BinaryProperty_t value octet sequence from an ASCII string, the length of the sequence shall be set to the number of characters in the string, counting the NUL terminating character, and each octet in the sequene shall be set to the ASCII value of the corresponding character in the string, including the NUL terminating character.
For example, if an object the string “ECDSA-SHA256” shall result in an octet sequence value with length 13 where the first octet is 0x45 (ASCII code for ‘E’) and the last octet is 0x00.

So we can mark this issue as duplicate of DDSSEC12-90

Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};
};@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};
};@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places. The correct IDL would be:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};

@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};

@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};

@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

This was entered in the wrong RTF

This issue was filed in the wrong RTF. It should have been filed on RPC over DDS 1.1 RTF. It has already been entered there. See https://issues.omg.org/browse/DDSRPC11-2.

The check_remote_participant row of Table 63 contains the text:

If the Permissions document contains a Grant for the remote
DomainParticipant and the Grant contains an allow rule on the
DomainParticipant domain_id, then the operation shall succeed and
return TRUE.

It seems like the intent is to ensure that there is some possible Action that this participant can do in the domain. That should take into account a <default>ALLOW</default> permission.

In general the <default> XML element seems to be not fully/consistently described in the section for Built-In Access Control. The xsd says it must be present, but section 9.4.1.3.2.3 says it may not be.

Merge with DDSSEC12-79

This issue impacts the same table/rules as https://issues.omg.org/browse/DDSSEC12-79

we propose to handle them toguether.

The syntax in DDS-XML containes places where an object references another object. This is done normally using an attribute with type elementNameReference defined in http://www.omg.org/spec/DDS-XML/20170301/dds-xml_domain_definitions_nonamespace.xsd

However the specification does not deny any rules/constraints on the references themselves. In fact those references must follow a precise syntax to uniquely select an element which require a full path down the containment hierarchy down to the selected element.

The specification should define this and provide some examples.

This issue was entered here in error. It was an issue for a different FTF

This issue should have been filed for http://issues.omg.org/browse/DDSXML

Therefore it should be closed here (and filed in the other FTF).

Section 7.3.7.3 defines CryptoHeader as inheriting from CryptoTransformIdentifier. However CryptoHeader is APPENDABLE and CryptoTransformIdentifier is FINAL.

This does not seem possible according to XTYPES.

Other places of the spec (section 9.5.2.3 "DDS:Crypto:AES-GCM-GMAC CryptoHeader") define it as final.

Change CryptoHeader definition in 7.3.7.3. to final

In section 7.3.7.3 "Mapping of the CryptoHeader SubmessageElement"
modify the extensibility of CryptoHeader from "APPENDABLE" to "FINAL" resulting in the following IDL:

@extensibility(FINAL)
struct CryptoHeader : CryptoTransformIdentifier  {
    // Extra plugin-specific information added below
    // PluginHeader   plugin_crypto_header_extra;
};

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

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

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

Some possibilities:

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

Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/
This document also discusses various approaches: https://www.xml.com/pub/a/2004/10/27/extend.html

Add mechanism to extend Governance and Permissions document

Define how the Governance and Permission documents could be extended and the rules to apply when processing the document and encountering an extension.

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

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

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

Add support for OCSP stapling

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

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

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

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

• 9.4.1.2.4.1 Domains element: "This element is delimited by the XML element <domain_id>."

• 9.4.1.2.7 Example Domain Governance document (non normative)
  ... "<domain_id>0</domain_id>" ...

• 9.4.1.3.2.3.1.1 Domains Section: "This Section is delimited by the XML element <domain_id>."

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

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

get_participant_sec_attributes, get_datawriter_sec_attributes, and get_datareader_sec_attributes return ParticipantSecurityAttributes and EndpointSecurityAttributes.

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

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

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

Add return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes

This proposal will add return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes.

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

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

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

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

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

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

Define PID for Sending Endpoint Security Attributes

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

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

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

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

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

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

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

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

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

However, in the normative IDL, is defined as:

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

This is, the IDL has two issues:

• "in HandshakeMessageToken handshake_message_in" should be removed
• "in HandshakeMessageToken handshake_message_out" should be marked as inout and renamed "handshake_message"

Fix Inconsistent begin_handshake_request in the IDL

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

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

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

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

Message Authentication
An alternative term for Data Origin Authentication.

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

Clarify Data Origin Authentication versus Non-Repudiation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes in Specification to Specify a Challenge Length and Fixing Typo

Define changes according to DDSSEC11-52.

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

Proposal:

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

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

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

Changes to Table 57

Perform the changes proposed in the issue description.

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

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

Define PID for Sending Participant Security Attributes

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

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

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

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

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

Remove references to SecureSubMsg and replace with SecureBodySubMsg in:

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

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

• 8.5.1.9.6 Operation: preprocess_secure_submsg: this needs to be modified to explain it now uses a prefix.
• 8.5.1.9.7 Operation: decode_datawriter_submessage: this needs to be modified to explain that it now uses a SecurePrefixSubMsg.
• 8.5.1.9.8 Operation: decode_datareader_submessage: this needs to be modified to explain that it now uses a SecurePrefixSubMsg.

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

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

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

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

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

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

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

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

Changes in Specification to correct logging facility

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

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

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

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

Changes in Specification to Specify SubjectName Format

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

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

is_access_protected	
is_discovery_protected	
is_submessage_protected	
is_payload_protected	
is_keyhash_obfuscated	
is_liveliness_protected	

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

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

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

Define Mechanism for Matching Plugin Specific Attributes

Define Mechanism for Matching Plugin Specific Attributes.

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

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

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

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

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

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

To correct this the above declaration should be replaced with:

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

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

Use explicit inheritance for BuitinTopics

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

Currently, section 9.3.2.3.2 says

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

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

Changes in Specification to apply SHA256 to DH shared secret

Specify changes to specification according to DDSSEC11-49

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

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

Update Figure 9 (Authentication plugin interaction state machine)

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

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

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

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

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

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

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

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

Not worth doing as it would break backwards interoperability

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

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

Correct VALIDATION_PENDING_CHALLENGE_MESSAGE

See issue description.

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

Fix validate_remote_identity on IDL and Document to be Consistent

This will apply the changes described in DDSSEC11-21

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

Duplicates DDSSEC11-21

Duplicates DDSSEC11-21

Description:

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

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

Proposal (see DDSSEC11-28):

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

Define Secure Volatile Endpoint Attributes and Simplify create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens

General proposal:

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

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

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

Two possible approaches:

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

• There are probably other approaches.

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

Merge with DDSSEC11-82

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

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

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

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

Close as duplicate of DDSSEC11-43

This will be handled with DDSSEC11-43

Several inconsistencies remain in the document:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To:

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

Also make that change to machine readable Governance XSD file

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

• Global replace of remote_participant_key with remote_participant_guid in the specification document
• Global replace of local_participant_key with local_participant_guid in the specification document
• Global replace of "local participant_key" with local_participant_guid in the specification document
• Global replace of participant_key with participant_guid in the specification document

• Replace replace of BuiltinTopicKey_t with GUID_t in the machine readable IDL dds_security_pugin_spis.idl operation validate_remote_identity
• Global replace of remote_participant_key with remote_participant_guid in the machine readable IDL dds_security_pugin_spis.idl

Address identified typos and inconsistencies

Apply the changes suggested in the issue description.

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

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

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

Change Specification to Use Empty AAD

Change the specification to use an empty AAD.

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

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

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

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

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

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

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

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

• If the number of matched DataReaders exceeds the specified maximum then the DataWriter has two possibilities:

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

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

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

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

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

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

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

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

Duplicate of DDSSEC11-6

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

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

• CRYPTO_TRANSFORMATION_KIND_AES128_GCM
• CRYPTO_TRANSFORMATION_KIND_AES256_GCM

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

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

Changes in Specification to Specify a Transformation Kind in Table 52

Specify changes according to DDSSEC11-53.

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

Table 58: replace SessionSalt and SessionHMACKey by SessionReceiverSpecificKey.

Perform the changes suggested in the Issue description

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

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

This will implement changes described in DDSSEC11-34

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

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

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

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

Improve AccessControl interface wrt check_local and check_remote operations

It is necessary to separate the security attributes into two constructs : TopicSecurityAttributes and EndpointSecurityAttributes. These inform the middleware which security operations must be invoked.

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

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

The Liveliness messages pertain two types of liveliness

• DataWriter Automatic Liveliness
• DataWriter Manual by Participant Liveliness

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

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

The specification should clarify this.

Apply the modifications suggested in the issue description and comments

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

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

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

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

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

Document: