Handling of key exchange opaque data

[steven-bellock]

In DSP277 the opaque data field in KEY_EXCHANGE / PSK_EXCHANGE is used by the Requester to specify which 277 versions it supports, and is used by the Responder to select the session's 277 version. Currently, libspdm, which requires 277 for secure sessions, is lenient on the opaque data evaluated by an endpoint. In particular https://github.com/DMTF/libspdm/blob/88803c35e1b4ddf20a39866e6f74b3e105861b0c/library/spdm_requester_lib/libspdm_req_key_exchange.c#L576-L585 Ie, if the Responder doesn't send any opaque data the Requester is OK with that. Do we want this behavior, or should it be more strict?

[jyao1]

Current behavior is that if integrator provisioned secured_message_version, then it is required. Otherwise, the opaque data is ignored. That leaves maximum flexibility, if both endpoints know how to process it without opaque data, based upon current spec. (everything is compatible)

It seems DSP0277 makes them mandatory

First, the SPDM Requester shall
advertise its list of supported version through the OpaqueData field of a Session-Secrets-Exchange request. The
Requester shall use the Secured Message opaque data format to specify its list in Supported version list data format.

Then, we need: 1) force integrator to register secured_message_version. 2) check the existence of opaque data.

Below code should be fixed:

    if (spdm_context->local_context.secured_message_version.spdm_version_count == 0) {
        return LIBSPDM_STATUS_SUCCESS;
    }

[steven-bellock]

Based on https://github.com/DMTF/libspdm/issues/1986#issuecomment-1528811101 let's require secured message versions and opaque data to establish a secure session.

[steven-bellock]

Now that I am older and wiser it looks like either the 277 version is negotiated or the transport binding specification (for example DSP0276) is negotiated. So libspdm needs to know, based on the transport binding specification, whether the version values are 277 or the transport binding specification itself.

I filed https://github.com/DMTF/SPDM-WG/issues/3509 to clear up some confusion on DSP0276