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

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.

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.

The file ptc/16-03-22 uses the wrong URL for primitive types.

It should use http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi not http://www.omg.org/spec/UML/20110701/UML.xmi

This I believe is a systemic problem due to a bug in Sparx Enterprise Architect.

Correct XMI file

As stated in the issue description the XMI file dds_security_plugins_model.xmi is incorrect.

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

• The root of the XSD document is the element "<dds>" whereas in section 9.4.1.3 and 9.4.1.4 this root is omitted and it jumps directly to the nested subelement "<permissions>."
• The machine readable XSD is correct as this is also consistent with the format for the Governance file which also has "<dds>" as root.
• Also the date format in the XSD file is inconsistent with the format that is used in sections 9.4.1.4 and 9.4.1.3.2.2.

Fixing inconsistencies with normative machine readable files

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

Most of the original list of points were addressed as part of the FTF2.
The remaining two points are copied below:
----------------------------------------------------
7.3.7 – missing section for SecuredPayload SubmessageElement
Or, [and i think this is better], replace everywhere SecuredPayload with
SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

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

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

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

7.3.7.4 SecureDataTag Element
Typo in second para:

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

Should be

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

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

7.3.7.8 SecureRTPSPrefixSubMsg Submessage

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

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

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

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

9.5.2.4 DDS:Crypto:AES-GCM-GMAC SecureDataBody

Second paragraph "SecureDataTag" should be "SecureDataBody".

The IDL does not include the 'struct' typename:

@Extensibility(FINAL_EXTENSIBILITY)
struct

;

Gerardo: This was already fixed by 182

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

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

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

Message structure shows contents as SecureDataTag. Should be
SecureDataHeader.

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

7.3.7 – missing section for SecuredPayload SubmessageElement

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

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

7.3.6.2 RTPS Submessage: SecureSubMsg

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

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

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

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

Mentions SecureSubMsg, but should be SecureBodySubMsg

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

7.3.7.6 SecurePrefixSubMsg Submessage

Mentions SecureSubMsg, should be SecurePrefixSubMsg

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

7.3.7.7 SecurePostfixSubMsg Submessage

Mentions SecureSubMsg, should be SecurePostfixSubMsg

Gerardo: Fixed in AB errata

Rename SecureDataHeader, SecurePayload, SecureDataTag

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

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

Table 55:

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

This :

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

should read

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

2. register_matched_remote_datareader(), second sentence.

This

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

should read

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

3. register_matched_remote_datawriter, sentence 2.

This

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

should read

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

Perform the corrections listed in the issue description

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

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

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

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

Correct names of new builtin topics

Correct the names according to the issue description

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

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

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

Add EndpointSecurityAttributes Parameter to register_local_datawriter /register_local_datareader

Add new parameter to register_local_datawriter and register_local_datareader: EndpointSecurityAttributes:

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

For consistency, similar change proposed to register local participant:

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

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

Issue already corrected in the FTF

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

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

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

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

• In section 9.6 (BuiltinLoggingPlugin) it says "NameValurPair" it should say "NameValuePair"

• In Figure 20 field "msgid" is "int" it should be "string" to be consistent with section 9.6

• In section 9.4.1.2 there are two occurrences of "Encrypt+MAC" this is ambiguous as it could be interpreted as "Encrypt and MAC" which s not considered best practice. It should say "Encrypt-then-MAC" to be more precise and match what the plugins do.

• Section 9.4.1.2.5.5 second paragraph says "This element may take the binary values TRUE or FALSE" instead it should say "This element may take the three possible values: NONE, SIGN, or ENCRYPT.''

• Section 4, definition of Key management. Remove the words "of the keys" from the definition as shown here: "...during their entire life cycle of the keys from creation to destruction."

• XML examples in Section 9.4.1.2.7 and 9.4.1.4 use encoding="utf-16" this should be changed to encoding="utf-8" to be consistent with the XSD in section 9.4.1.2.2, 9.4.1.3, and all the machine readable documents (both XSD and example XMLs).

• Section 9.4.1.2.4.5 (Liveliness Protection Kind element) in the 3rd and last paragraph says: "The discovery protection kind..." it should say "The liveliness protection kind..."

Perform the corrections listed in the issue description

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

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

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

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

Extend governance to indicate whether mac_per_readers are desired

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

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

• There shall be a new ExtendedProtectionKind simple type that is is similar to the existing ProtectionKind enumeration except with extra values: ENCRYPT_WITH_ORIGIN_AUTHENTICATION and SIGN_WITH_ORIGIN_AUTHENTICATION

• The type associated with the <rtps_protection_kind>, <metadata_protection_kind>, <discovery_protection_kind> and <liveliness_protection_kind> shall be changed to be ExtendedProtectionKind instead of the current ProtectionKind

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

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/

Defer to RTF2

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

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 RTF2

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