Clear up incompatibility issue in section 5.1.3.1

[johngray-dev]

In RFC 5.1.3.1 it contains a description of Key expansion that should occur when the Key is larger than the one-way function:

In the above protectionAlg, the salt value is appended to the shared secret input. The OWF is then applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration. The output of the final iteration (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]

From David: I just came across the weird situation that the definition of PBM in RFC 4210 section 5.1.3.1 describes

• for the case that the base key, derived using the one-way-function, is too short for the HMAC key input - a different (and needlessly complicated) padding than the one that was specified in RFC 4211 section 4.4, which uses a simple zero padding defined in RFC 2104 section 2.

Are you aware of this inconsistency, which can lead to incompatibility of implementations in case the size of the hash alg used as the OWF is smaller than of the hash alg used for the HMAC? Looks like most implementations follow RFC 4211 here. What does your implementation do?

[johngray-dev]

Yes, we have definitely noticed this situation. We had incorrectly implemented the key expansion in 4210 in our own proprietary version (we call this “entrust-style”), and recently corrected it to also support the RFC 4210 key expansion (we call it “rfc4210-style”). So I take it you have implemented the 4211 way, which is different that what we did, and therefore we would probably not be compatible with something like a 3DES SHA1 MAC, or AES SHA1 or any combination where the key used is larger than the OWF.

I would hope one possible mitigation is that most implementations would have moved on to using a SHA2 based OWF in which case they should be good in almost all cases.

We had a bunch of internal discussions on this today, and it seems less horrible than I first thought…

RFC 4211 seems to only talk about HMAC, and in these cases key expansion is never needed. The OWF will run first to derive K before being put into the Mac function and the HMac will internally digest if needed, so essentially no external expansion is needed. RFC 4210 talks about key expansion when K > H, and it is not required when K <= H

So, in this regard, 4211 and 4210 will not lead to an incompatibility. If you need to use (for example) an AES MAC algorithm and key expansion is required, you would follow RFC 4210, if you don’t need key expansion you can follow 4211 and/or 4210.

It is just very unclear and totally confusing, so I still think we want a clarifying sentence or two in RFC 4210-bis.

We could state something like:

"RFC 4210 section 5.1.3.1 gives a method of key expansion to be used when the key used for a Mac algorithm is larger than the size of the one-way-function. RFC 4211 section 4.4 did not mention this key expansion method and gives an example using HMAC algorithms where key expansion is not needed. It is recognized that this omission in RFC 4211 can lead to confusion and possible incompatibility if RFC 4210 key expansion is not used when needed. Therefore, when key expansion is required (when K > H) the key expansion defined in RFC 4210 section 5.1.3.1 MUST be used."

[johngray-dev]

I just noticed in RFC 4211 in section 4.4 says:

All implementations MUST support SHA-1.

So I don't know if adding the suggested text above becomes problematic. Ideally people wouldn't use SHA1 anymore, but I suppose if they do then we would be recommending they use a key the same size as SHA1 (which I guess would be HMAC SHA1 or AES128 SHA1 or combinations like that for compatibility.

[HBrock]

@johngray-dev, thank you for the explanation.

While writing CMP Algorithms we came across the requirement of CRMF implementing SHA-1. Russ wrote RFC 9045 updating these requirements. RFC9045 states: MUST implement id-PasswordBasedMAC and MAY implement PBMAC1 For PasswordBasedMAC: MUST implement SHA-256 for owf and MUST implement HMAC-SHA256 and SHOULD implement AES-GMAC for mac

In RFC 9481 we list SHA2 and SHAKE as potential owf in Section 2 and SHA2-based HMAC, AES-GMAC, and SHAKE-based KMAC as potential mac in Section 6.2. Section 7.1 of RFC 9481 requires SHA-256 and HMAC-SHA256 to be used with PasswordBasedMAC.

What does this change about the requirement for key expansion?

[HBrock]

As addition to rfc4210bis Section 5.1.3.1 we could write the following based on John's proposal:

current text: "5.1.3.1. Shared Secret Information

In this case, the sender and recipient share secret information with sufficient entropy (established via out-of-band means). PKIProtection will contain a MAC value and the protectionAlg MAY be one of the options described in CMP Algorithms Section 6.1 [RFC9481].

The following text gives further details on PasswordBasedMac. It is mentioned in Section 6.1.1 of [RFC9481] for backward compatibility. More modern alternatives are listed in Section 6.1 of [RFC9481].

  id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
  PBMParameter ::= SEQUENCE {
     salt                OCTET STRING,
     owf                 AlgorithmIdentifier,
     iterationCount      INTEGER,
     mac                 AlgorithmIdentifier
  }

In the above protectionAlg, the salt value is appended to the shared secret input. The OWF is then applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration. The output of the final iteration (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]

Note: It is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) to reduce the overhead associated with PasswordBasedMac computation."

new text:

"5.1.3.1. Shared Secret Information

In this case, the sender and recipient share secret information with sufficient entropy (established via out-of-band means). PKIProtection will contain a MAC value and the protectionAlg MAY be one of the options described in CMP Algorithms Section 6.1 [RFC9481].

The algorithm identifier id-PasswordBasedMac is defined in Section 4.4 of RFC 4211 and updated by RFC 9045. It is mentioned in Section 6.1.1 of [RFC9481] for backward compatibility. More modern alternatives are listed in Section 6.1 of [RFC9481].

  id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
  PBMParameter ::= SEQUENCE {
     salt                OCTET STRING,
     owf                 AlgorithmIdentifier,
     iterationCount      INTEGER,
     mac                 AlgorithmIdentifier
  }

The following text gives a method of key expansion to be used when the key used for a MAC-algorithm is larger than the size of the one-way-function.

Note: RFC 4211 Section 4.4 and RFC 9045 do not mention this key expansion method and gives an example using HMAC algorithms where key expansion is not needed. It is recognized that this omission in RFC 4211 can lead to confusion and possible incompatibility if RFC 4210 key expansion is not used when needed. Therefore, when key expansion is required (when K > H) the key expansion defined in in the following text MUST be used.

In the above protectionAlg, the salt value is appended to the shared secret input. The OWF is then applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration. The output of the final iteration (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]

Note: It is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) to reduce the overhead associated with PasswordBasedMac computation."

[HBrock]

conclusion 26.02.2024: Take the changes written above with the following changes. old: "The following text gives a method of key expansion to be used when the key used for a MAC-algorithm is larger than the size of the one-way-function." new: "The following text gives a method of key expansion to be used when the MAC-algorithm requires an input length that is larger than the size of the one-way-function."

[HBrock]

I responded to the email communication from San Francisco IETF las July on this matter asking Russ, David H. , and Mark for their opinion on

• Is the text in rfc4210bis Section 5.1.3.1 sufficiently clarifying the issue?
• How to proceed regarding a potential erratum to RFC 4211 or even RFC 9045?

Russ, David H., Mark

I am uncertain if there was final agreement on how to handle this issue back last summer. I did not see further
communication on this topic and no errata on RFC 4211. Maybe I missed something.

In the rfc4210bis editors group we discussed this issue again some days ago, see
https://github.com/lamps-wg/cmp-updates/issues/48, and proposed clarifying text for rfc4210bis, see
https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc4210bis.html#name-shared-secret-information. I am
planning to submit the version on github latest on Monday.

The conclusion was, as long as HMAC is used as mac with id-PasswordBasedMAC, there is no need for key expansion as
HMAC has no required input length. In general, an implementation could use different MAC algorithms for messages
protection as well as for POP. 

RFC 9481 updates RFC 4210. In RFC 9481 we list SHA2 and SHAKE as potential owf in Section 2 and SHA2-based HMAC,
AES-GMAC, and SHAKE-based KMAC as potential mac in Section 6.2. Section 7.1 of RFC 9481 requires SHA-256 and
HMAC-SHA256 to be used with id-PasswordBasedMAC.

RFC 9045 updates RFC 4211. RFC9045 states: MUST implement id-PasswordBasedMAC and MAY implement PBMAC1,
and for id-PasswordBasedMAC: MUST implement SHA-256 for owf and MUST implement HMAC-SHA256 and SHOULD
implement AES-GMAC for mac.

Both CMP and CRMF do not restrict implementations to only using the above listed algorithms with id-PasswordBasedMAC
for message protection or POP. Therefore, I think there is still need for aligning both specifications regarding key expansion.

I have two questions:
Is the text in rfc4210bis Section 5.1.3.1 sufficiently clarifying the issue? 
How to proceed regarding a potential erratum to RFC 4211 or even RFC 9045?

Hendrik

[HBrock]

David H. and Russ reported consent with the text proposed in rfc4210bis on email. I did not get any feedback from Mark. No one indicated need for an errata on RFC 4211 or RFC 9045 so fare.

I will wait for further feedback until after IETF and close the issue if nothing more comes.

[HBrock]

During LAMPS meeting today, no one raised the request to file a erratum to RFC 4211.