Validator test case 3.5.15

[tmarkey64]

The Validator will flag an error for 3.5.15 if the capabilities MUT_AUTH_CAP is not set and baseAsymAlg is not zero, but the baseAsymAlg is set to the signature algorithm for the purpose of signature generation and verification. There is not requirement in the specification that this be zero if mutual authentication is not supported. Signature generation and verification is also used for Challenge and Measurements.

[tmarkey64]

The same argument goes for test case 3.6.15 as well.

[steven-bellock]

@tmarkey64

The Validator will flag an error for 3.5.15 if the capabilities MUT_AUTH_CAP is not set and baseAsymAlg...

That baseAsymAlg is actually ReqBaseAsymAlg, ie the Requester's algorithm used to sign transcripts during mutual authentication. If mutual authentication is not supported by Requester then ReqBaseAsymAlg is not present and that is reflected by the Responder.

[steven-bellock]

@tmarkey64 if this resolves your issue please close this issue.

[tmarkey64]

Thanks Steven, I have closed this issue.

[tmarkey64]

Hi Steven,
I examined the request for 3.5.15 (spdm_test_case_algorithms_success_11), the 3rd Algorithm Request Structure has AlgType set to 4 (ReqBaseAsymAlg), the AlgSupported field is set to 0x1FF. Here is the raw request:

00000000 11 E3 04 00 30 00 01 00 FF 01 00 00 3F 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 02 20 3F 00 03 20 07 00 04 20 FF 01 05 20 01 00
00000030 45 76 65 00 00 00 00 00 00 00 00 00 00 00 00 00 

The responder in this case selected from the AlgSupported field, but the responder's capability flags did not include the MUT_AUTH_CAP, so it fails here (spdm_responder_test3_algorithms.c), where req_base_asym_alg is set to 0x80, which is included in the requesters bit map of supported assymetric algorithms above.

  if (((test_buffer->rsp_cap_flags & SPDM_GET_CAPABILITIES_RESPONSE_FLAGS_MUT_AUTH_CAP) != 0) &&
        ((req_base_asym_alg != 0xFFFF) && (req_base_asym_alg != 0x0))) {
        test_result = COMMON_TEST_RESULT_PASS;
    } else if (((test_buffer->rsp_cap_flags & SPDM_GET_CAPABILITIES_RESPONSE_FLAGS_MUT_AUTH_CAP) ==
                0) &&
               (req_base_asym_alg == 0x0)) {
        test_result = COMMON_TEST_RESULT_PASS;
    } else {
        test_result = COMMON_TEST_RESULT_FAIL;  << -- fails here.
    }

[steven-bellock]

The responder in this case selected from the AlgSupported field, but the responder's capability flags did not include the MUT_AUTH_CAP, so it fails here

That is correct. If Responder's MUT_AUTH_CAP is 0 then Responder's ReqBaseAsymAlg should be 0 or that field should not exist in the response.

[tmarkey64]

Hi Steven, Thanks for the clarification. I see now that this clarification was added in the 1.2 version of the specification. "If the Responder is generating the signature, the selected cryptographic signing algorithm is indicated in exactly one of BaseAsymSel or ExtAsymSel in ALGORITHMS message. If the Requester is generating the signature, the selected cryptographic signing algorithm is indicated in ReqBaseAsymAlg of RespAlgStruct in ALGORITHMS message.". I will go ahead and close the issue again.

[tmarkey64]

Issue has clarified and resolved.

[chanss-park]

Hi @steven-bellock . Currently, Validator will process the following test scenario as fail.

• Requester sets GET_CAPABILITIES with MUT_AUTH_CAP=0.
• Responder sets CAPABILITIES with MUT_AUTH_CAP=1.
• Requester sends NEGOTIATE_ALGORITHMS with non-zero ReqBaseAsymAlg.
• Responder sends ALGORITHMS without ReqBaseAsymAlg field (because Requester did not set MUT_AUTH_CAP).

SPDM-Responder-Validator/library/spdm_responder_conformance_test_lib/spdm_responder_test_3_algorithms.c

Lines 1380 to 1389 in 626dfbd

	if (((test_buffer->rsp_cap_flags & SPDM_GET_CAPABILITIES_RESPONSE_FLAGS_MUT_AUTH_CAP) != 0) &&
	((req_base_asym_alg != 0xFFFF) && (req_base_asym_alg != 0x0))) {
	test_result = COMMON_TEST_RESULT_PASS;
	} else if (((test_buffer->rsp_cap_flags & SPDM_GET_CAPABILITIES_RESPONSE_FLAGS_MUT_AUTH_CAP) ==
	0) &&
	(req_base_asym_alg == 0x0)) {
	test_result = COMMON_TEST_RESULT_PASS;
	} else {
	test_result = COMMON_TEST_RESULT_FAIL;
	}

I have two questions related to the test scenario above.

1. What does it mean that Requester sends non-zero ReqBaseAsymAlg when MUT_AUTH_CAP=0?
2. Should Responder process ReqBaseAsymAlg even though Requester did not set MUT_AUTH_CAP?
   According to the following statement in SPDM 1.3, it seems that Responder can choose nothing for ReqBaseAsymAlg.
   If the Responder will not send any messages that require a signature, this value should be set to zero.

[steven-bellock]

• Requester sets GET_CAPABILITIES with MUT_AUTH_CAP=0.
• Requester sends NEGOTIATE_ALGORITHMS with non-zero ReqBaseAsymAlg.

@jyao1 @chanss-park this is a bug in the validator. Requester's ReqBaseAsymAlg should not exist if Requester's MUT_AUTH_CAP is 0.

SPDM-Responder-Validator/library/spdm_responder_conformance_test_lib/spdm_responder_test_3_algorithms.c

Lines 56 to 65 in 626dfbd

	data32 = SPDM_GET_CAPABILITIES_REQUEST_FLAGS_CERT_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_CHAL_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_ENCRYPT_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_MAC_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_KEY_EX_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_ENCAP_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_HBEAT_CAP |
	SPDM_GET_CAPABILITIES_REQUEST_FLAGS_KEY_UPD_CAP;
	libspdm_set_data(spdm_context, LIBSPDM_DATA_CAPABILITY_FLAGS, &parameter,
	&data32, sizeof(data32));

[chanss-park]

2. Should Responder process ReqBaseAsymAlg even though Requester did not set MUT_AUTH_CAP?
   According to the following statement in SPDM 1.3, it seems that Responder can choose nothing for ReqBaseAsymAlg.
   If the Responder will not send any messages that require a signature, this value should be set to zero.

Hi Steven, thank you for checking.
For the 2nd question, how should Responder process the case ? Invalid request error or just ignore the ReqBaseAsymAlg ?

[jyao1]

@jyao1 @chanss-park this is a bug in the validator. Requester's ReqBaseAsymAlg should not exist if Requester's MUT_AUTH_CAP is 0.

Yes. I agree it is a bug. If MUT_AUTH_CAP is 0, requester should set 0 to ReqBaseAsymAlg, or make it absent.

[steven-bellock]

For the 2nd question, how should Responder process the case ? Invalid request error or just ignore the ReqBaseAsymAlg ?

That is apparently a complicated question. Let me review the specification(s), as ReqBaseAsymAlg has had special treatment throughout the years.

[steven-bellock]

Yes. I agree it is a bug. If MUT_AUTH_CAP is 0, requester should set 0 to ReqBaseAsymAlg, or make it absent.

Requester cannot set it 0. The AlgType must be absent.

For the 2nd question, how should Responder process the case ? Invalid request error or just ignore the ReqBaseAsymAlg ?

Yes, that should be an error. Interestingly libspdm does not handle it that way precisely. I will file an issue against libspdm.

[chanss-park]

Hi Steven,
thank you for clarification.