-
Key: DDSSEC_-14
-
Legacy Issue Number: 19777
-
Status: closed
-
Source: ZettaScale Technology ( Mr. Julien Enoch)
-
Summary:
In §8.3.2.9.3 the IdentityCredential parameter passed to the validate_local_identity operation is described as following:
"The nature and configuration of the credential is specific to each Authentication plugin implementation"In §8.3.2.1:
"The specific content of the IdentityCredential shall be defined by each Authentication plugin specialization and it may not be used by some Authentication plugin specializations. The interpretation of the contents as well as the mechanism used to pass it to the Authentication plugin shall be specified by each plugin implementation.”In §9.3.2.1:
"The DDS:Auth:PKI-RSA/DSA-DH plugin shall set the attributes of the IdentityCredential objects as specified in the table below."So it seems it's up to the AuthenticationPlugin to create the IdentityCredential (it's the only one to know how to set/interprate the attributes). Moreover, we could imagine the credential to be provided by various ways which are specific to the AuthenticationPlugin implentation (e.g. security hardware as USB Credential Provider or fingerprint reader...)
Nevertheless, the middleware is supposed to pass the IdentityCredential to the validate_local_identity operation. But it has no way to create or get this IdentityCredential object.
We suggest to replace this IdentityCredential parameter with the DomainId and the QoS Policies of the DomainParticipant to validate. Thus, the AuthenticationPlugin has a way to make distinction between 2 local DomainParticipant to validate, and can internally applies different credentials.
-
Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
-
Disposition: Resolved — DDS-Security 1.0
-
Disposition Summary:
Specify how to configure authentication and access control plugins. Also specify which cryto families shall be supported
The resolution of this issue should is to define the configuration of the Authentication and Permissions plugins more explicitly such that they can be “plugged” in across vendors without requiring changes to the core DDS.
Doing this requires a general-purpose mechanism to configure the plugins from DDS. This is accomplished by adding a PropertyQosPolicy to the DomainParticipantQos consisting of Name-Value pairs. This reuses the “Property_t” type already defined in 7.2.1 making it a “first-class” element within the DomainParticipantQos and also visible via discovery.
The parameters to Authentication::validate_local_identity() and AccessControl::validate_local_permissions() need to be adjusted to receive those properties.
Support for the following crypto families should be specified:
Identity/Authentication: RSA-2048 and Elliptic Curve prime256v1with
SharedSecret: Diffie-Hellman and Elliptic Curve Diffie-Hellman
Encryption, MAC: AES128-GCM (Gallois Counter Mode) AES128-GMAC -
Updated: Tue, 12 Jul 2016 14:45 GMT
-
Attachments:
- Issue14_Section_7.3.6.3-6.docx 126 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Issue14_Section_7.3.7.6-9.docx 103 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Issue14_Section_9.5.3.3.4.docx 156 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Issue14_Table_31.docx 104 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Issue14_Table_40.docx 95 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Issue14_Table_55.docx 132 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
DDSSEC_ — More explicit Authentication and Permissions configuration
- Key: DDSSEC_-14
- OMG Task Force: DDS Security 1.0 FTF 2