Subject: [tcpm] Question on crypto algo usage for TCP-AO

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 2 Aug 2021 18:36:29 +0530

Hi,

Section 3.1.1 of RFC 5926 describes how to derive the traffic key of
desired length to be used for the MAC calculation, especially when the
KDF_alg produces fewer bits than the key length required for the MAC_alg.

<snip>

   The output of multiple PRF invocations is simply concatenated.  For

   the Traffic_Key, values of multiple PRF invocations are concatenated

   and truncated as needed to create a Traffic_Key of the desired

   length.  For instance, if one were using KDF_HMAC_SHA1, which uses a

   160-bit internal PRF to generate 320 bits of data, one would execute

   the PRF twice, once with i=1 and once with i=2.  The result would be

   the entire output of the first invocation concatenated with the

   second invocation.  For example,

  Traffic_Key =

          KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||

          KDF_alg(Master_Key, 2 || Label || Context || Output_length)

   If the number of bits required is not an exact multiple of the output

   size of the PRF, then the output of the final invocation of the PRF

   is truncated as necessary.

</snip>

The question I have is, what if the first invocation of the above PRF
itself produces more bits than the key length required by the MAC
calculation. Should the output of the first invocation be truncated? For
e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 as
the KDF_alg, should the output of the foll. be truncated to 128 bits (since
it would produce a 160 bit output whereas AES-128-CMAC requires a 128-bit
key)?
KDF_alg(Master_Key, 1 || Label || Context || Output_length)

Regards,
Muthu

---

From: Joseph Touch <[email-masked]>
Date: Tue, 3 Aug 2021 20:18:52 -0700

Hi all,

I would post this to the security area WG for better feedback, given it’s only transport in its use by TCP.

My view is that this is not particularly unambiguous, as noted below.

Joe

> On Aug 2, 2021, at 6:06 AM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
> Hi,
> 
> Section 3.1.1 of RFC 5926 describes how to derive the traffic key of desired length to be used for the MAC calculation, especially when the KDF_alg produces fewer bits than the key length required for the MAC_alg.
> 
> <snip>
> The question I have is, what if the first invocation of the above PRF itself produces more bits than the key length required by the MAC calculation. Should the output of the first invocation be truncated?

In that case, the first invocation of PRF is also the “final” invocation, as mentioned in the last paragraph, because you have enough bits. So yes, then you truncate.

> For e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 as the KDF_alg, should the output of the foll. be truncated to 128 bits (since it would produce a 160 bit output whereas AES-128-CMAC requires a 128-bit key)?

Yes; I don’t understand why this seems unambiguous.

> 
> Regards,
> Muthu
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 4 Aug 2021 10:08:25 +0530

Hi Joe,

Thanks for your response. I agree this follows logically, but wanted to
check if anyone has a different opinion since it impacts interoperability.
Perhaps, if we ever take up rfc5926bis, we could add a clarification note..

Regards,
Muthu

On Wed, Aug 4, 2021 at 8:48 AM Joseph Touch <[email-masked]> wrote:

> calculation. Should the output of the first invocation be truncated?
>
>
> In that case, the first invocation of PRF is also the “final” invocation,
> as mentioned in the last paragraph, because you have enough bits. So yes,
> then you truncate.
>
> For e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and
> KDF_HMAC_SHA1 as the KDF_alg, should the output of the foll. be truncated
> to 128 bits (since it would produce a 160 bit output whereas AES-128-CMAC
> requires a 128-bit key)?