Direct POP - hash of Rand instead of plain INTEGER

[HBrock]

Coming back to the discussion in the LAMPS session. In the Direct POP in CMC the hash of the challenge is returned. If I got it right, it was mentioned that it may not be secure, if the challenge is responded in plain.

In CMP Rand containing a sequence of an INTEGER and the sender's GeneralName is the challenge and is provides as EnvelopedData. In the response the INTEGER is returned in plain.

If people think this is insecure, we should update the response to responding the hash of Rand. This was also a proposal from Thom Wiggers.

[HBrock]

Mike responded on email: CMC says this for the direct POP challenge response:

 DecryptedPOP ::= SEQUENCE {
       bodyPartID     BodyPartID,
       thePOPAlgID    AlgorithmIdentifier,
       thePOP         OCTET STRING
  }

   thePOPAlgID  identifies the algorithm to be used in computing the
       return POP value.
   thePOP  contains the possession proof.  This value is computed by
      the POPAlgID using the POP Proof Value and the request.

And the example shows:

         thePOPAlgID HMAC-SHA1,
         thePOP <HMAC computed value goes here>}}

It would not be a terrible idea to do the same thing in CMP. I’m not sure that it is exactly an attack since in CMP an attacker would also need to be able to forge the overall HMAC message protection, but it is maybe a good idea to align with CMC?

[HBrock]

I think that the CMP request message can be extended easily. But extending the existing response message will not work. Therefore we either need to redefine the existing response message with CMP V3 or we need to define a new response message.

Current syntax according to rfc4210bis:

PKIBody ::= CHOICE { -- message-specific body elements … popdecc [5] POPODecKeyChallContent, --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response … }

POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption or key agreement key certification -- request (in the same order as these requests appear in -- CertReqMessages).

-- encryptedRand was added in [RFCXXXX]

Challenge ::= SEQUENCE { owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL, -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. (Note that a different -- INTEGER MUST be used for each Challenge.) challenge OCTET STRING, -- MUST be used for cmp2000(2) popdecc messages and MUST be -- the encryption of Rand (using a mechanism depending on the -- private key type). -- MUST be an empty OCTET STRING for cmp2021(3) popdecc messages. -- Note: Using challenge omitting the optional encryptedRand is -- bit-compatible to the syntax without adding this optional -- field. encryptedRand [0] EnvelopedData OPTIONAL -- MUST be omitted for cmp2000(2) popdecc messages. -- MUST be used for cmp2021(3) popdecc messages and MUST contain -- the encrypted value of Rand using CMS EnvelopedData using the -- key management technique depending on the private key type as -- defined in Section 5.2.2. }

-- Rand was added in [RFC9480]

Rand ::= SEQUENCE { -- Rand is encrypted involving the public key to form the content of -- challenge or encryptedRand in POPODecKeyChallContent int INTEGER, -- the randomly generated INTEGER A (above) sender GeneralName -- the sender's name (as included in PKIHeader) }

POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption or key agreement key certification -- request (in the same order as these requests appear in -- CertReqMessages). The retrieved INTEGER A (above) is returned to -- the sender of the corresponding Challenge.

Updated Syntax:

PKIBody ::= CHOICE { -- message-specific body elements … popdecc [5] POPODecKeyChallContent, --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response … popdecrV3 [27] POPODecKeyRespContentV3 – pop Response in CMP V3 }

POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption or key agreement key certification -- request (in the same order as these requests appear in -- CertReqMessages).

Challenge ::= SEQUENCE { owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL, -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. (Note that a different -- INTEGER MUST be used for each Challenge.) challenge OCTET STRING, -- MUST be used for cmp2000(2) popdecc messages and MUST be -- the encryption of Rand (using a mechanism depending on the -- private key type). -- MUST be an empty OCTET STRING for cmp2021(3) popdecc messages. -- Note: Using challenge omitting the optional encryptedRand is -- bit-compatible to the syntax without adding this optional -- field. encryptedRand [0] EnvelopedData OPTIONAL, -- MUST be omitted for cmp2000(2) popdecc messages. -- MUST be used for cmp2021(3) popdecc messages and MUST contain -- the encrypted value of Rand using CMS EnvelopedData using the -- key management technique depending on the private key type as -- defined in Section 5.2.2. popAlgID [1] AlgorithmIdentifier OPTIONAL -- MUST be omitted for cmp2000(2) popdecc messages. -- MUST be used for cmp2021(3) popdecc messages and MUST -- identify the algorithm to be used in computing the return POP value. }

Rand ::= SEQUENCE { -- Rand is encrypted involving the public key to form the content of -- challenge or encryptedRand in POPODecKeyChallContent int INTEGER, -- the randomly generated INTEGER A (above) sender GeneralName -- the sender's name (as included in PKIHeader) }

POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- MUST be used for cmp2000(2) popdecr messages -- One INTEGER per encryption or key agreement key certification -- request (in the same order as these requests appear in -- CertReqMessages). The retrieved INTEGER A (above) is returned to -- the sender of the corresponding Challenge.

POPODecKeyRespContentV3 ::= SEQUENCE OF ChallengeResponse -- MUST be used for cmp2001(3) popdecrV3 messages -- One ChallengeResponse per encryption or key agreement key -- certification request (in the same order as these requests appear in -- CertReqMessages). The hash of the retrieved Rand including the -- INTEGER A (above) is returned to the sender of the corresponding -- Challenge.

ChallengeResponse ::= SEQUENCE { popAlgID AlgorithmIdentifier, -- MUST be the value from Callenge pop OCTET STRING -- MUST contain the possession proof. This value is computed by -- the popAlgID using the Rand value. }

Introducing the new PKIBody choice popdecrV3 is not nice. Does anyone have a better idea? @johngray-dev what do you think?

[HBrock]

@johngray-dev Do you have any feedback to this issue? @ounsworth what do you think with regard to alignment with CMCbis? @DDvO do you have any opinion?

As the draft is already at IESG for AD review, we need to hurry, if we want to change anything here. Therefore, you quick feedback is appreciated! :-) I am also happy to close this issue without any further change to the draft if we feel like it is not needed. If we decide to implement this change, it will most likely end up in a new WGLC. But this should not be the blocking point of course.

[DDvO]

For clarity, this must have been the concern raised by Thom on July 10th:

Regarding security consideration 8.2, have you considered returning H(rand) instead of rand to further avoid these decryption oracles? However, arguably the derivation of challenge encryption key should be set up in a way to sufficiently domain-separate this. Again, this comes back to how the challenge encryption keys are set up.

[DDvO]

@johngray-dev Do you have any feedback to this issue? @ounsworth what do you think with regard to alignment with CMCbis? @DDvO do you have any opinion?

As the draft is already at IESG for AD review, we need to hurry, if we want to change anything here. Therefore, you quick feedback is appreciated! :-) I am also happy to close this issue without any further change to the draft if we feel like it is not needed. If we decide to implement this change, it will most likely end up in a new WGLC. But this should not be the blocking point of course.

I do not believe that there really is a security problem with the CMP client responding the decrypted challenge in plain (unencrypted non-hashed form).

The concern was that the unencrypted response could be used as part of a decryption oracle attack. This would require sending many challenges (possibly even with specifically chosen input data).

Yet this cannot happen here because for a given private key, a cert request will be sent only once (or at least not often; even if the client later sent requests for certificate updates using the same key pair, quite long time would have passed between any such requests), and a legitimate CMP server (typically, the CA) reacts with a direct POP challenge at most once for each cert request, and the client would accept such a challenge only once per cert request that it sent.

(Moreover, direct POP requests by an illegitimate CMP server (posing as the CA) would be rejected by the client because such an attacker would not be able to provide valid CMP message protection.)

Thus I do not see the need for making any further (even worse, last-minute!) changes to the direct POP mechanism.

As far as you agree with this argumentation, it may be taken as the basis for a paragraph to be added regarding this concern in the security considerations section.

[johngray-dev]

I think the concern would be a malicious entity that sent in the encrypted challenge many times (though they would have to know how to protect the message in the first place....). You mention a legitimate CMP server will react with a direct POP challenge at most once for each cert request. Is that stated anywhere? If not then I maybe that just needs to be stated somewhere in normative language in the security concerns section. That maybe overkill, but if it is a concern then we could say something like:

• A CMP server MUST not respond to a direct POP challenge for a cert request more than once. If a subsequent request for the same certificate request is received, the CMP server MUST send an error indicating a POP challenge has already been received for the specific cert request.

If the same cert requests should be allowed (as David mentioned maybe a re-keying of the same cert request), then maybe some type of retry interval should be recommended?

Thom's mentioned the following:

• Regarding security consideration 8.2, have you considered returning H(rand) instead of rand to further avoid these decryption oracles? However, arguably the derivation of challenge encryption key should be set up in a way to sufficiently domain-separate this. Again, this comes back to how the challenge encryption keys are set up.

Another way to mitigate is we could say something like the key management technique should use sufficient context (domain separation) information when deriving the keys for the challenge. We mention key transport, key agreement, password and KEM as key management techniques (Section 5.2.2). Perhaps this is something to state in the security concerns section.

I thinking making a whole new PKIBody message with caveats when to use it may be a bit of overkill. It would definitely solve the issue. I guess we need to convince ourselves there is an issue to resolve first of all. I think the biggest hurdle is the message protection, so unless we think that isn't sufficient, then we need to do something.

[HBrock]

I thinking making a whole new PKIBody message with caveats when to use it may be a bit of overkill. It would definitely solve the issue. I guess we need to convince ourselves there is an issue to resolve first of all. I think the biggest hurdle is the message protection, so unless we think that isn't sufficient, then we need to do something.

In fact, it is not only with Direct POP that we have the situation that data is transmitted from the CMP server to the CMP client, where the data has been encrypted with the public key of the CMP client. This is also the case with indirect POP and central key generation, where the certificate or private key is transmitted in encrypted form. In the opposite direction, CMS EnvelopdData from the CMP client to the CMP server is also specified for the transfer of revocation passphrases and private keys as POP and for key escrow/recovery. In all these cases, we rely on the security of CMS Enveloped Data! Spontaneously, I see no reason why we should rely less on the security of CMS Enveloped Data for Direct POP and take special precautions. If we don't trust in the security of CMS EnvelopedData, we have a much bigger problem elsewhere, especially with transferal of private keys. The transfer of H(Rand) would be cryptographically nicer, but the change to the syntax would be ugly, and we would only address a potential problem for a corner case. If you agree, I vote for not changing from Rand --> H(Rand). Or am I missing something here? Please add you vote as comment.

[HBrock]

The analysis in my previous comment was not entirely complete.

Yes, we rely on the security of CMS EnvelopedData in all the cases listed above. But only in two cases can an attacker simply have access to ciphertext and plaintext.

• Indirect POP: The attacker would have to obtain the new certificate in plain from other communications. In certConf, only H(certificate) is transmitted.
• Direct POP: The attacker gets ciphertext and plaintext from the Rand of the same transaction.

I think that's what makes the difference. The question now is, should we take countermeasures? In both cases, the content of the ciphertext must have a valid ASN.1 structure. This MUST be checked by the CMP client, as stated in Section 8.2. An attacker also cannot choose the ciphertext if the message is signed by the CMP server.

Possible countermeasures could be the following:

1. Answer H(Rand) instead of Rand
2. Expand Section 8.2 with a security consideration that a CMP server MUST only provide an encrypted challenge/certificate once for a given public-private key pair.
3. Note that in the cases described above, sufficient domain separation must be applied to the key management technique used. At the moment, it is not quite clear to me how we can specify this simply and unambiguously.
4. Message protection by the CMP server is required for POPODecKeyChallContent messages.
5. No further countermeasures if we believe that the attack is sufficiently unlikely.

@johngray-dev , @ounsworth , and @DDvO What do you think? Do you have anything else to add to this analysis? If not, what countermeasure do you vote for?

[ounsworth]

DDvO

I do not believe that there really is a security problem with the CMP client responding the decrypted challenge in plain (unencrypted non-hashed form).

Ultimately, I think I agree with this.

I think we have now considered it, and it is not worth the effort to make any change.

[HBrock]

Thanks to all of you for responding to this issue. I am also fine with changing nothing further. If I got John's and David's comments right, they are also not convinced that there is need for action. Please reopen this issue if you think we need further discussion.

[johngray-dev]

I am okay with this outcome. If it were to come up again during the write-up processes we could add a sentence to security considerations.