3.2.5. Association Command Class, version 3

The Association Command Class version 3 introduces the capability to discover the highest security class of a target when issuing controlling commands via association groups.

3.2.5.1. Compatibility Considerations

\requirement{CC:0085.03.00.21.001}{4}

If a node supports the version 3 of this Command Class and the Multi Channel Association Command Class, it MUST support the Multi Channel Association Command Class, version 4 or newer.

3.2.5.2. Interoperability Considerations

\requirement{CC:0085.03.00.31.001}{0}

Any supporting node MUST learn the granted security classes of a destination before sending controlling commands to a destination via association groups.

Commands are marked as controlling or supporting in [26].

\requirement{CC:0085.03.00.32.001}{0}

The following discovery is RECOMMENDED:

  1. Request the NIF and read its contents, look for S2/Supervision and S0

  2. If S2 is supported, for every granted S2 key starting from the highest:

    1. Issue the S2 encrypted controlling command using Supervision Get encapsulation (and Multi Channel encapsulation if End Point source or destination)

    2. If receiving a Supervision Report, stop the discovery and use the current S2 Security Class for controlling the target NodeID.

    3. Else if no answer is returned (or S2 Nonce Reports), proceed with a lower granted S2 key.

  3. If S0 is supported, try using S0:

    1. If S2 was in the NIF :

      1. Issue the S0 encrypted controlling command using Supervision Get encapsulation

      2. If receiving a Supervision Report, stop the discovery and use S0 as the Security Class to control the target NodeID

    2. If S2 was not in the NIF:

      1. Issue a S0 encrypted S0 Security Command Supported Get command

      2. If receiving S0 encrypted S0 Security Command Supported Report command, stop the discovery and use S0 for controlling the target NodeID

  4. Settle for non-secure level if no Security Class was found. Supervision encapsulation MAY be used non-securely only if it was in the NIF.

\requirement{CC:0085.03.00.33.001}{0}

A supporting node MAY use another algorithm using the following assumptions:

\requirement{CC:0085.03.00.31.002}{0}

  • A controlling node MUST NOT associate Node A to a Node B destination that does not support the Command Class that the Node A will be controlling.

\requirement{CC:0085.03.00.31.003}{0}

  • A controlling node MUST NOT associate Node A to a Node B destination if Node A was not granted Node B’s highest Security Class.

Role Type Specification provides recommended timeouts when waiting for responses to Get type commands.

Further, when issuing (supporting or controlling) commands via an association group:

\requirement{CC:0085.03.00.31.004}{0}

\requirement{CC:0085.03.00.33.002}{0}

  • A supporting node MAY use Supervision encapsulation if the destination supports the Supervision Command Class.

\requirement{CC:0085.03.00.31.006}{0}

  • If the destination supports the Supervision Command Class, a supporting node MUST use Supervision encapsulation to send Access Control-related reports, Access Control-related control commands and critical sensors and notifications reports (defined by the manufacturer).

\requirement{CC:0085.03.00.32.002}{0}

  • The sender SHOULD implement an algorithm to retry up to three times on no reply to a supervised command.

\requirement{CC:0085.03.00.31.005}{0}

  • A supporting node MUST NOT use Multi Command encapsulation if the destination does not support the Multi Command Command Class.