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:

IDL:

            boolean
                encode_serialized_data(
                    inout OctetSeq                encoded_buffer,
                    in    OctetSeq                plain_buffer,
                    in    DatawriterCryptoHandle  sending_datawriter_crypto,
                    inout SecurityException       ex);

Name should be changed in the idl to encode_serialized_payload, and we should add missing extra_inline_qos.

Same issue for decode_serialized_data.

Change encode_serialized_data/decode_serialized_data in the IDL to be Consistent

The IDL is wrong, we will fix it to match the rest of the specification.

The fact that we are calling encode_serialized_submessage on top of the result of encode_serialized_payload allows the use of different key material. This is in fact needed to support the relay mode.

However the spec is confusing regarding this. In several places (e.g. register_local_datawriter in Table 55) and likewise in create_local_datawroter_cryptotokens seems to indicate that a single KeyMaterial is created.

This should all be clarified so it is possible to use separate key material for the two operations.

Seems like this should be stated in register_local_datawriter and register_matched_remote_datareader

Duplicates DDSSEC11-11 (and its resolution)

This issue is already handled by the resolution of DDSSEC11-14 (DDSSEC11-126)

As also filed under http://issues.omg.org/browse/DDS15-153, current definition used by DDS-SECURITY for BuiltinTopicKey_t is inconsistent with current DDS specification.

Changing BuiltinTopicKey_t definition would be risky, as multiple implementations may rely on what has been the standard for a long time.

Also, at this point we should try to avoid changing the wire representation for DDS-SECURITY.

As a solution that will not break compatibility, we can define a new GUID_t type that is an array of 16 octets, and use this one in the security specification.

Replace use of BuiltinTopicKey_t with GUID_t

To avoid confusion the DDS-Security specification shall use the GUID_t type as defined by the DDS-RTPS specification, and not the BuiltinTopicKey_t.

An attacker could do an easy Denial of Service attack by just injecting Participant Discovery Unregister&Dispose messages.

Current DDS Security spec does not consider any mechanism to prevent this.

Proposal

This proposal allows for checking the authenticity of unregister&dispose messages at the same time that provides a secure way for changing local participant properties after authentication. The proposal is based in adding a new inline qos "PARTICIPANT_SESSION_SIGNATURE" to the Participant Discovery messages from secure participants.

• The content of the inline qos will be:
  • Two fields for avoiding replay attacks:
    • A NONCE (c.nonce) set to a value generated upon local participant creation.
    • An epoch (c.epoch) incremented each time there is a change in the announced participant discovery information.
  • A signature generated using the private key of the participant. The signature is generated from the following input:
    • c.nonce
    • c.epoch
    • The info state for the sample.
    • (if the sample contains data) md5(c.pData)

Upon reception of a Participant Discovery Message, and only if the remote participant is authenticated with us, the local participant will check if the received message would trigger a change in the properties or liveliness state of the remote participant. If the received message would trigger a change, the local participant will verify the signature using the certificate of the remote participant. If the verification fails, the message will be ignored. If the verification succeeds, the message will be parsed. In order to make this verification possible, the auth.plugin will expose three new APIs:

• get_max_private_signature_size: get the max. size of a private signature.
• private_sign: signs a set of bytes using the local participant private key.
• verify_private_signature: verifies a set of bytes against a signature using the remote participant public certificate.

Note: An operation private_sign is a bit too powerful. Would allow the application to sign anything it wants so it is not good practice. The operation should control what kind of data is signed so arbitrary bytes cannot be signed.

Note that if the remote Participant is not authenticated, no additional checks are done and messages are just parsed as usual.

Add a DCPSParticipantsSecure buitin Topic

To address this issue the specification shall add a new builtin Topic to send the ParticipantBuiltinTopicData to authenticated applications. This shall be called the "DCPSParticipantsSecure" builtin Topic.

After they authenticate the DomainParticipants will ignore data on the (unsecure) "DCPSParticipants" builtin Topic and only process ParticipantBuiltinTopicData data on the "DCPSParticipantsSecure" builtin Topic.

This topic will be secured the same way as the other secure "discovery" topics.

After two participants are mutually authenticated and authorized, there are two scenarios that could potentially lead to communication not to recover:

Let's call the Participant sending token1 "requester" and the Participant sending token2 "replier".

Scenario 1

The "replier" participant removes the "requester" participant because of a liveliness loss, there is no way the system can recover:

• Requester participant still knows about the replier (he did not lose the liveliness), so no AI for him.
• Replier participant will wait for a request that will never arrive.

Scenario 2

The "requester" participant removes the "replier" participant because of a liveliness loss, there is no way the system can recover:

• Requester participant sends periodic auth messages (token 1).
• Replier participant still knows about the requester (he did not lose the liveliness), so no AI for him. , It just drop the messages he receives (as if they were duplicates for steps already done) by the replier.

The problem is, there is no standardized mechanism for triggering a new "Figure 9 - Authentication plugin interaction state machine".

Other Scenarios

There may be other scenarios as described in DDSSEC11-81.

Proposal

Add a new mechanism that allow triggering the creation of a new Authentication state machine, as we do when we discover a remote participant. In order to do this in a secure way, we need to keep the old authentication session until this new state machine fully succeeds the authentication process. Also, we need to do this in a way an attacker cannot provoke a Denial of Service Attack by continuously triggering re-authentications.

The proposal here is to solve these problem by adding a new "auth.req" message that asks the remote participant to create a new authentication state machine. If that authentication state machine succeeds, the old one will be replaced:

• Add a new GMCLASSID (“dds.sec.auth.req”) so it is easly identified as a potential request of restarting the whole authentication process for a participant.
• If processed (only if the remote participant is authenticated), this request will trigger the creation of a parallel state for a remote participant. This is, would be equivalent to receive discovery pData from new participant. It will therefore trigger the creation of a new authentication state machine.
• Only if a whole authentication completes, the old remote participant state is removed and the new one triggers the authorization and all the remaining steps.
• For the request, define a new HandshakeMessageToken ("DDS:Auth:PKI-DH:1.0+AuthReq") containing a NONCE.
• That NONCE is the random number the Participant mean to use as part of the challenge process. This will be the same challenge will be used as part of the token1 (or token2) we send.
• Received auth_request will be ignored by peers that are not authenticated with us.
• Received auth_request will be processed by peers fully authenticated with us, used as a hint about the other remote participant could be willing to restart authentication.
• Received NONCE will be compared against the random challenge we will receive in the next token1 (or token2). If that matches, means that the remote participant was the one generating the auth_request, so the authentication can continue. If it does not match, we will return VALIDATION_NOT_OK for that token.
• If the authentication completes, we will remove old state and replace with new one.
• In order to make the above possible, we need to move the generation of the local challenge to the validate_remote_identity step. That will be stored as part of the remote_identity_handle, so it can be used during the authentication process. Also, if the current state machine was triggered by the reception of an auth.request, we need also to store in the remote_identity_handle the "expected" remote challenge.

Define New Authentication Request Mechanism

This proposal will define a new Authentication Request mechanism for requesting for a re-authentication.

IDL states that there exists one function: get_endpoint_sec_attributes.
Table 23 lists get_datawriter_sec_attributes and get_datareader_sec_attributes separately.
As does 8.4.2.6.23/24. (8.4.2.6.23 has a typo in the headline: "dataRwriter")
Table 48 makes no mention of any of these functions.

Combine with DDSSEC11-16

This issue affects the same APIs that are being refactored by DDSSEC11-16. Therefore it is best to merge it with that issue.

The parameter "in Properties str_properties" is not covered in the specification document, yet is a parameter in the IDL interface.

Remove extra Properties parameter from check_create_topic in IDL file

The IDL seems to be the one that is wrong as there the specification does not mention the "properties" parameter on the operation AccessControl::check_create_topic. Consequently the parameter should be removed in the IDL file.

According to DDS-RTPS specification version 2.2 section 9.3.1.2 (Mapping of the EntityId_t) the last octet of the EntityId_t part of GUID for a builtin DataWriter and DataReader takes a specific value that depends on whether the builtin entity is used to send Topic whose data-type is keyed or unkeyed.

RTPS uses the name EntityKind to refer to this last octet in the EntityId_t.
According to Table 9.1 of the DDS-RTPS specification:

• A builtin DataWriter of a keyed TopicType shall have EntityKind 0xc2.
• A builtin DataReader of a keyed TopicType shall have EntityKind 0xc7.

• A builtin DataWriter of a non-keyed TopicType shall have EntityKind 0xc3.
• A builtin DataReader of a non-keyed TopicType shall have EntityKind 0xc4.

This is inconsistent with some of the values defines in Table 9 ( section 7.3.7.1) of the DDS-Security 1.0 spec. In particular the following ones:

• BuiltinParticipantStatelessMessageWriter has EntityKind 0xc2 but it should be 0xc3 because its TopicType has no key.

• BuiltinParticipantStatelessMessageReader has EntityKind 0xc7 but it should be 0xc4 because its TopicType has no key.

• BuiltinParticipantVolatileMessageSecureWriter has EntityKind 0xc2 but it should be 0xc3 because its TopicType has no key.

• BuiltinParticipantVolatileMessageSecureReader has EntityKind 0xc7 but it should be 0xc4 because its TopicType has no key.

*Correct EntityId_t for the builtin writers and readers of ParticipantStatelessMessage and ParticipantVolatileSecureMessage *

See Issue description

The spec defines the retcode VALIDATION_OK_FINAL_MESSAGE in Table 19 and in http://www.omg.org/spec/DDS-SECURITY/20160303/dds_security_plugin_spis.idl.

However, there are multiple uses of wrong VALIDATION_OK_WITH_FINAL_MESSAGE .

*Replace VALIDATION_OK_WITH_FINAL_MESSAGE Occurrences with VALIDATION_OK_FINAL_MESSAGE *

Replace the following VALIDATION_OK_WITH_FINAL_MESSAGE with VALIDATION_OK_FINAL_MESSAGE:

• In Figure 9 – Authentication plugin interaction state machine.
• In Figure 22 – Authentication sequence diagram with discovered DomainParticipant.
• In 8.8.2.2 Behavior when allow_unauthenticated_participants is set to FALSE, step 11.
• In Table 41 – Actions undertaken by the operations of the builtin Authentication plugin:
  • In "process_handshake on a handshake_handle created bybegin_handshake_request"
  • In "get_shared_secret"
  • In "get_authenticated_peer_credential_token"

BuiltinLoggingType under Figure 20 – Logging Plugin Model (8.6.2 Logging Plugin Model) is not consistent with the IDL in 9.6 Builtin Logging Plugin.

• facility is an octet in the IDL (a string in the figure).
• hostname is a string in the IDL (a byte in the figure).
• IDL contains a field appname. Figure contains procname.
• procid is a string in the IDL (an int in the figure).
• msgid is a string in the IDL (an int in the figure).

Proposal:

• Update the figure to be consistent with IDL.

Fix BuiltinLoggingType under Figure 20 – Logging Plugin Model To be Consistent with IDL

In Figure 20 – Logging Plugin Model To be Consistent with IDL:

• Change facility type to octet.
• Change hostname type to string.
• Replace procname with appname.
• Change procid type to string.
• Change msgid type to string.

Table 17 – SecurityException class uses the type SecurityExceptionCode without defining it anywhere.

It seems like it should be defined as a long as it is a 'code' parallel to the 'minor code' which is defined as a long.

Since SecurityExceptionCode only appears in this table the simples solution is to replace it with a long

Fix Table 17 SecurityException class

Replace the undefined type 'SecurityExceptionCode' with 'long' in Table 17.

In 8.8.6 AccessControl behavior with remote participant discovery, we state:

If the ParticipantSecurityAttributes object returned by the AccessControl operation
get_participant_sec_attributes has the is_access_protected attribute set to
FALSE, the DomainParticipant may discover DomainParticipants that cannot be authenticated
because they either lack support for the authentication protocol or they fail the authentication protocol.
These “Unauthenticated” DomainParticipant entities shall be matched and considered
“Unauthenticated” DomainParticipant entities.

Also in 8.8.7.1 AccessControl behavior with discovered endpoints from “Unauthenticated” DomainParticipant:

Note that, as specified in 8.8.2.2, a DomainParticipant for whom the
ParticipantSecurityAttributes object returned by the AccessControl operation
get_participant_sec_attributes has the is_access_protected attribute set to
TRUE, cannot be matched with an “Unauthenticated” DomainParticipant and therefore cannot
discover any endpoints from an “Unauthenticated” DomainParticipant.

This is overlapping with allow_unauthenticated_participants. If allow_unauthenticated_participants, then we should allow for unauthenticated participants independently of is_access_protected. In fact, we will not call to any of the AccessControl (nor any other plugin) APIs for that unauthenticated participant.

For authenticated participants, we should do all the checkings depending on the value for is_access_protected .

Duplicates DDSSEC11-14 (and its resolution)

Duplicates DDSSEC11-14 (resolved as DDSSEC11-126)

Current version of the specification defines is_payload_protected EndpointSecurity attribute. While this is useful for letting the DDS middleware know if it needs to call to security plugin operations for the payload, it is not giving information about the used protection (sign or encrypt).

This information is needed by the DDS middleware to make a decision about the kind of KeyHash used (see 7.3.4 Mandatory use of the KeyHash for encrypted messages).

Add is_key_protected

This proposal will add a new EndpointSecurityAttribute: is_payload_obfuscated, so the middleware can take decisions regarding the format for the keyhash.

In the DDS-SECURITY specification, the following statement could lead to some confusion:

9.4.1.2.4.4 Discovery Protection Kind element
The builtin endpoints shall never apply cryptographic transformations to the SecuredPayload
submessage element.

The wording is not clear. It is suggesting that there should be a SecuredPayload submessage element whose contents are identical to the plaintext, i.e. not transformed.

It should be changed to something like:

• The builtin endpoints shall never apply payload-level cryptographic transformations.

Modify Confusing Sentence about Builtin Endpoints

Change sentence to be more clear.

The Permissions XSD for the <allow_rule> and <deny_rule> elements allows for zero topics to be specified. In that case, does the rule match ANY topic or NO topics?

Modify description of permissions grant rules and XSD

Make it clear that lacking <publish> Criteria, a rule does not match any topics names for publishing. Likewise lacking a <subscribe> Criteria a rule would match no topics for subscribing.

These clarifications should be added to 9.4.1.3.2.3.1.2 (Publish Section) and 9.4.1.3.2.3.1.3 (Subscribe Section)

Modify the XSD for the Permissions document to make the <topics> section mandatory within the <publish> and <subscribe> sections.

This would impact the omg_shared_ca_permissions.xsd file.
Also this affects the omg_shared_ca_permissions_example.xml in that the rule below is invalid:

            <allow_rule>
                <domains>
                    <id>0</id>
                </domains>
                <publish>
                </publish>
                <subscribe></subscribe>
            </allow_rule>

This rule should be changed to remove the empty <publish> and <subscribe> elements. This change does not modify the meaning of the rule.

In addition the copy of the example XML that appears in 9.4.1.4 (DomainParticipant example permissions document (non normative)) needs to also be updated.

We need to pass the local big-endian serialized ParticipantBuiltinTopicData to begin_handshake_request and begin_handshake_reply so that they can include it in the outgoing handshake message as c.pdata (DDS Security spec Tables 38 and 39).

Proposal is to add a new input parameter to both begin_handshake_request and begin_handshake_reply. That parameter will consist on a buffer with the big endian CDR serialization of the participant data :

Add serialized_participant_data to begin_handshake_request and begin_handshake_reply

Add serialized_participant_data to begin_handshake_request and begin_handshake_reply

Assuming all functions in the AccessControl interface should return a boolean value.

get_permissions_token and get_permissions_credential_token:
IDL states a boolean return value, which is also implied by 8.2.4.6.17/18. In both cases the Permissions*Token is an inout parameter.
Table 23 claims the Permissions*Token is the returned value.

validate_local_permissions and validate_remote_permissions:
Stated to return a PermissionsHandle. This is consistent in all sources, so this is perhaps correct, but breaks the pattern.

Fix get__token in Table 23 To Be Consistent*

This will move PermissionsToken and PermissionsCredentialToken to the list of regular parameters, and add boolean as return value.

NOT_ALLOWED_BY_SEC is not prefixed with "RETCODE_".
This applies to both the IDL and the specification document.

Rename NOT_ALLOWED_BY_SEC with NOT_ALLOWED_BY_SECURITY

The document will be changed so that return code NOT_ALLOWED_BY_SEC will be renamed to NOT_ALLOWED_BY_SECURITY.

The machine-readable IDL file (dds_security_plugins_spi.idl) will be changed to that NOT_ALLOWED_BY_SEC will become RETCODE_NOT_ALLOWED_BY_SECURITY.

This appears 6 times.

• Once in the table of content
• Twice in section 7.2.8
• Three times in section 8.8.1

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.

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

The behavior of these endpoints with regards to the security plugins is controlled by fields in the ParticipantSecurityAttributes, specifically is_discovery_protected and is_liveliness_protected.

However the behavior of regular (application-defined) endpoints with regards to the security plugins is controlled by the value of the EndpointSecurityAttributes that are specific to each Endpoint.

This difference in treatment complicates the specification as well as the implementation. It also limits what can be done with the builtin endpoints.

A better solution would be to reuse the EndpointSecurityAttributes to specify the configuration of the builtin endpoints. This can be done by replacing the is_discovery_protected and is_liveliness_protected booleans with the EndpointSecurityAttributes fields for each type of endpoint as in:

struct ParticipantSecurityAttributes {
    ....
    EndpointSecurityAttributes discovery_endpoint_attributes;
    EndpointSecurityAttributes liveliness_endpoint_attributes;
    ...
};

That way the DDS core can treat the builtin endpoints as any other endpoint with regards to security.

Note that this approach is already followed for the ParticipantVolatileMessageSecureMessage. Its behavior is specified in 7.4.4.2 given its EndpointSecurityAttributes which are hardcoded in the specification.

Define the TopicSecurityAttributes for the secure builtin topics

The cryptographic behavior of the secure builtin topics (for example DCPSPublicationsSecure) can be configured via existing elements in the DomainGovernance file. Clearly define how those elements impact the secure builtin topics.

The DDS-SECURITY specification is not specifying the endianness to use in the ciphertext. This can lead to interoperability issues.

In particular:

• "9.5.3.3.4.1 Format of the SecureDataHeader Submessage Element" and "9.5.3.3.4.3 Format of the SecureDataTag Submessage Element".
  • Should use the submessage endianness.
• Section 9.5.3.3.4.2 Format of the SecureDataBody Submessage Element
  • When this is the content of the BODY submessage, the endianness should be the one in the submessage.
  • When this is an encrypted payload, the specification should define a default endianness. Proposal: big endian.

EDIT
After the discussion in the comments below, we decided to specify the endianness for the submessage elements to be Big Endian.

Specify Endianness to be Used in Submessage Elements

Define changes according to the discussion under DDSSEC11-54.

A 'rule' in the Permissions document can include any number of <data_tags> elements. Each data_tags element contains one or more <tag> elements. For example

<publish>
  <topics><topic>A*</topic></topics>
  <data_tags>
     <tag>
          <name>a</name>
          <value>aVal</value>
     </tag>
     <tag>
          <name>b</name>
          <value>bVal</value>
     </tag>
  </data_tags>
  <data_tags>
     <tag>
          <name>a</name>
          <value>aVal</value>
     </tag>
     <tag>
          <name>c</name>
          <value>cVal</value>
     </tag>
  </data_tags>
</publish>

The spec should be more clear about the circumstances under which this will and will not match with the tags provided to the check_create_datawriter/reader() and check_remote_datawriter/reader() operations.

For example, would the above rule match a Writer with the following datatag qos:

 
{ { a, aVal } } 

or:

 
{ {a, aVal}, {b, bVal}, {c, cVal} }

Proposal:
Add the following statement to the last paragraph of 9.4.1.3.2.3:

For the data-tag criterion to match, the complete set of tags listed within one of the data_tags elements must match the complete set of data tags associated with the entity in question.

Clarify the matching criteria for partitions and data_tags

The matching criteria will be explained. All sections must match.

• The criteria for the sections within an "allow" rule is that the endpoint partitions/tags are a subset of the ones that are legal.
• The criteria for the sections within a "deny" rule is that the endpoint partitions/tags cannot overlap any of the ones listed as illegal.

Conservative defaults will be used when the section is not specified.
<partitions> within an allow rule defaults to the empty partition
<data_tags> within an allow rule defaults to no tags
<partitions> within a deny rule defaults to "*"
<data_tags> within a deny rule defaults to all tags

In current version of the spec, ParticipantSecurityAttributes only contains is_access_protected and is_rtps_protected.

To be consistent with other fields like topic_rule's metadata_protection_kind (mapped to is_submessage_protected by the spec) or domain_rule's rtps_protection_kind (mapped to is_rtps_protected by the spec)), we should do the following modifications to the spec:

• ParticipantSecurityAttributes: add new field is_discovery_protected
  • is_discovery_protected: Indicates the value of is_submessage_protected for the Builtin Discovery Secure endpoints.
• Discovery Protection Kind element, add the following to 9.4.1.2.4.5 Discovery Protection Kind element:

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

Define is_discovery_protected ParticipantSecurityAttribute

Add an entry for is_discovery_protected to Table 21 in section 8.4.2.4. This field controls whether the Crypto plugin operations are called on the DCPSPublicationsSecure and DCPSSubscriptionsSecure.

Edit section 9.4.1.2.4.4 (Discovery Protection Kind element) to explain that the setting of the <discovery_protection_kind> element determines the value of the ParticipantSecurityAttributes returned by the AccessControl::get_participant_sec_attributes. Specifically the field is_discovery_protected

Table 51 indicates that the key_material binary property should have as value the CDR serialized representation of a structure but it does not define an Endianness for the serialization. It should.

Also in 8.3.2.9.4 , 8.3.2.9.5, and 8.3.2.9.6 it talks about message_data being the "cdr serialization" where it is not needed to say anything about serialization.

Proposal: Use BIg Endian to be consistent with similar decisions on the DDS-Security spec

Changes in Specification to Use Big Endian Serialization For Crypto Tokens and To Remove Unnecessary Serialization Details for message_data

Specify changes to specification according to DDSSEC11-42

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

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.

Examples would be nice but can be deferred

Having example permission files would help implementors of the specification so it is considered a desirable feature.

However given the limited time to complete the RTF 1 the task force decided to defer to the next RTF

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.

In the case of the DDS-RTPS wire protocol, the version of the RTPS protocol can be determined from the RTPS header that starts each message.

DDS-Security adds messages to RTPS. In that sense it extends the protocol creating an SRTPS protocol (with additional builtin endpoints, submessages, and submessage elements). However there does not seem to be an obvious way to determine this version from just observing the packets on the wire.

Not having this version may complicate creating future revisions that do not break interoperability and also the development or use of packet level tools like wireshark.

One possible solution is to use the minor version of the RTPS protocol to also encode the version of the secure RTPS protocol. For example current version of RTPS is 2.2 we could say that from now onwards the "odd" version numbers represent "secure" versions of the proceeding "even" version. So the result of DDS Security RTF 1 will be RTPS 2.3 and the result of DDS Interoperability RTF3 will be RTPS 2.4. If these RTFs do not alternate we just skip the intermediate version. For example if DDS Interoperability RTF4 comes without an interweaving DDS-Security we just jump to RTPS 2.6

Proposal:
This DDS-Security RTF will cycle the version of RTPS to the next (2.3)
The current RTPS RTF3 will take that into consideration and indicate the range of sub-messages reserved for security. RTPS RTF3 will then set the RTPS protocol version to "2.4"

Onwards each RTF will update the RTPS version (assuming there are changes to the protocol) because they should know about each other.

In addition we need to say that the Plugin name has the version as part of the name and that the version should be parsed in a certain way to check compatibility. I.e. not require an exact match of the plugin names.

We should also add a "version" properties for each plugin as in dds.sec.auth.version and dds.sec.access,version, these would be propagated.
Also add a dds.sec.auth.common to have an overall version of the spec...

Revise version of RTPS and provide rules for plugin versions

Since the DDS-Security specification adds new RTPS submessages it should also update the version of RTPS to the next one (2.3).

The DDS-Security should spec should also "reserve" a range of RTPS Discovery parameterIds 0x1XXX for the use of the DDS-Security spec and future revisions.

Section 9.3.2 (DDS:Auth:PKI-DH Types) should indicate that the IdentityToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
<PluginClassName>:<MajorVersion>.<MinorVersion>
If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not attempt authentication.

Section 9.4.2.2 (DDS:Access:Permissions PermissionsToken) should indicate that the PermissionsToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
<PluginClassName>:<MajorVersion>.<MinorVersion>
If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not try to interpret the permissions document of the other participant.