DDS-SECURITY 1.2 RTF Avatar
  1. OMG Issue

DDSSEC12 — class_id string in Authentication/Permissions Tokens should include spec version

Open Closed All
  • Key: DDSSEC12-83
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The class_id attribute in various Tokens includes the Plugin Name and a version number. The intention was that the version number would track the specification version so that it could be used to understand the format of the Token.

    However this is not done consistently. Currently the following class_id are used:

    token class_id
    IdentityToken "DDS:Auth:PKI-DH:1.0"
    AuthenticatedPeerCredentialToken "DDS:Auth:PKI-DH:1.0"
    AuthRequestMessageToken "DDS:Auth:PKI-DH:1.0+AuthReq"
    HandshakeRequestMessageToken "DDS:Auth:PKI-DH:1.0+Req"
    HandshakeReplyMessageToken "DDS:Auth:PKI-DH:1.0+Reply"
    HandshakeFinalMessageToken "DDS:Auth:PKI-DH:1.0+Final”
    PermissionsToken "DDS:Access:Permissions:1.0"
    PermissionsCredentialToken "DDS:Access:PermissionsCredential"
    CryptoToken "DDS:Crypto:AES_GCM_GMAC"

    As it can be seen some class_ids are missing the version number. The ones that have it use "1.0" instead of "1.1" which is the version of the spec. Finally when there are multiple tokens with the same class ID a suffix preceded by a "+" is uses to differentiate them, but this is not done in all cases.

    The goal of this issue is to correct this irregularities. So DDS Security version 1.2 should modify the Token as follows:

    token class_id
    IdentityToken "DDS:Auth:PKI-DH:1.2"
    AuthenticatedPeerCredentialToken "DDS:Auth:PKI-DH:1.2+AuthPeer"
    AuthRequestMessageToken "DDS:Auth:PKI-DH:1.2+AuthReq"
    HandshakeRequestMessageToken "DDS:Auth:PKI-DH:1.2+Req"
    HandshakeReplyMessageToken "DDS:Auth:PKI-DH:1.2+Reply"
    HandshakeFinalMessageToken "DDS:Auth:PKI-DH:1.2+Final”
    PermissionsToken "DDS:Access:Permissions:1.2"
    PermissionsCredentialToken "DDS:Access:Permissions:1.2+Cred"
    CryptoToken "DDS:Crypto:AES_GCM_GMAC:1.2"

    Note that this change is not intended to break backwards interoperability. So the proposal could/should be adjusted to ensure that. Specifically the change in the name for the PermissionsCredentialToken should not impact interoperability as this token is not exchanged between participants. The same is true for the addition of the "+AuthPeer" to the AuthenticatedPeerCredentialToken.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 17 Dec 2019 00:26 GMT
  • Updated: Tue, 17 Dec 2019 00:51 GMT