DDS-Security 1.0 FTF Avatar
  1. OMG Issue

DDSSEC_ — More explicit Authentication and Permissions configuration

  • 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: