Response protection not correctly chosen

[RufusJWB]

Note: Issue tracker is ONLY used for reporting bugs.

Issue Report

If a client sends a request message protected with a shared secret the response might be protected with a certificate.

Expected Behavior

The response should be protected with the shared secret.

Current Behavior

The response might be protected with a certificate

Possible Solution

as discussed with @DDvO and @Akretsch

[RufusJWB]

@DDvO and myself stumbled about this problem yesterday again, and it becomes more and more annoying.

[DDvO]

The original report was about the cmpRaComponent not fulfilling the following requirement from the LCMPP section 4.1.5:

The protection of all messages MUST be MAC-based. Therefore, extraCerts fields of all messages do not contain CMP protection certificates and associated chains.

The additional point that came up yesterday is that when the server receives a request message with MAC-based protection using some shared secret, clearly the response that it sends on this request must be protected using the same shared secret. Looks like that this is not the case and this this is not even explicitly specified in the LCMPP.

[HBrock]

RFC 9483 Section 4.1.5 clearly states "Therefore, the request and response messages are MAC-protected using this shared secret information."

[DDvO]

Thanks for pointing this out - on Friday I somehow overlooked this sentence.

Anyway, this necessity implies that it makes little sense that the CmpRaComponent and the LightweightCmpRa allow configuring a shared secret in its downstream outputCredentials (which are part of the CmpMessageInterface, described here or here, respectively ) because it must use the same secret as the one it used to verify the protection of the request message it received on one of its downstream interfaces and this secret has already been configured in the VerificationContext (which is part of the same CmpMessageInterface).

[DDvO]

@RufusJWB please note the following statement in https://github.com/siemens/LightweightCmpRa/tree/main/doc/config#the-cmpmessageinterface-value:

The current implementation supports only one SharedSecret per VerificationContext. So the only way to specify more than one shared secret per DownstreamConfiguration or UpstreamConfiguration is to use more than one certProfile.

So for the configuration of the LightweightCmpRA, which you copied, already when using PBM on receiving a request, only one shared secret per certProfile (and bodyType) is supported, and due to the just mentioned inherent dependency within the downstream interface regarding the use of shared secrets, this implies that also when protecting response messages only one shared secret per certProfile and bodyType can be supported at the level of LightweightCmpRa.

[DDvO]

On the other hand, looks like the CmpRaComponent is flexible to use any number of shared secrets - see default byte[] getSharedSecret(final byte[] senderKID) where senderKID acts as the user name that should map to the shared secret.

[DDvO]

Moreover, at LightweightCmpRa level, the config doc says:

Note: The configuration does not support specifying both signature-based and MAC-based protection. Consequently, the RA will always protect as configured, even if the (downstream) client uses a different way of protecting its requests. As the Lightweight CMP profile forbids mixing signature-based and MAC-based protection within the same transaction, care needs to be taken such that the EE and RA configurations are consistent for all types of requests. To this end it can be helpful to differentiate via certificate profiles.

For the demo, we can resort to specifying re-protection with the right shared secret for ip messages, like this:

DownstreamConfiguration:
  - bodyType: ip
    ReprotectMode: reprotect
    OutputCredentials:
      SharedSecret:
        SharedSecret: "myPresharedSecret"
        SenderKID: "sender_RA"
        PasswordBasedMacAlgorithm: "PBM"
    VerificationContext:
      sharedSecret: "myPresharedSecret"
  # for any other bodyType:
  - OutputCredentials:
      Signature:
        keyStore: credentials/CMP_LRA_DOWNSTREAM_Keystore.p12
        password:  Password
    VerificationContext:
      trustedCertificates:
        - "credentials/CMP_EE_Root.pem"
        - "credentials/ENROLL_Root.pem"

[RufusJWB]

As just discussed, I believe the sharedSecretAlgorithm and the sharedSecret must not be defined in the OutputCredentials but must be copied from the protection of the VerificationContext.

[DDvO]

To sum up our yesterday's exchange on Teams:

Right - when using MAC-based (re-)protection of the response to a request with MAC-based protection, all data (shared secret, algorithm and any alg parameters) need to be copied over. Therefore it does not make sense to configure such data on the downstream output side of the RA.

Consequently, also the client side can/must expect that on a MAC-based request it sends, the response is protected with the same credentials and algorithm (+ params). Thus it does not make sense, either, to configure symmetric credentials for verifying responses received from upstream. Instead, the configuration for the outgoing upstream interface is re-used.

Regarding the decision whether the RA shall re-protect, joint decision was to keep the current solution to have this configurable. That is, the configurator has the choice to specify (generally, or for instance just for IR transactions) that the RA must re-protect responses it received from upstream when passing them on towards the client.

[DDvO]

A further detail, for which we did not have the time to mention it yesterday:

In the error case the RA receives a request message with MAC-based protection but cannot verify it, the RA cannot (surely) know which is the right symmetric data to use for protecting its error response. Here the RA is free to use any configured asymmetric downstream credentials, and if there are none configured, it will send the error unprotected.

[kiron-mx]

Implemented behaviour for cmpRaComponent.

As discussed with @DDvO and @HBrock: The cmpClient will still need to be adjusted accordingly. Complying with LCMPP section 3.5 in combination with section 4.1.5, the cmpClient should no longer accept signature-based response protection, if a MAC-based request was sent.

[DDvO]

Very nice.

I suppose you meant the Java-based CMP client that comes with the CmpRaComponent. Actually I had touched this point also above two weeks before:

Consequently, also the client side can/must expect that on a MAC-based request it sends, the response is protected with the same credentials and algorithm (+ params).

[kiron-mx]

@RufusJWB this issue has been resolved in #106 and is pending to be merged into the main branch. Additionally, I added a note in the lightweightCmpRa config documentation to describe the behaviour.