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

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 <touch@strayalpha.com> wrote:

> 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 <muthu.arul@gmail.com>
> 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 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?
>
>
> 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)?
> KDF_alg(Master_Key, 1 || Label || Context || Output_length)
>
>
> Yes; I don’t understand why this seems unambiguous.
>
>
> Regards,
> Muthu
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>