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

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Wed, 04 August 2021 04:38 UTC

Return-Path: <muthu.arul@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BEF3A09DB for <tcpm@ietfa.amsl.com>; Tue, 3 Aug 2021 21:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfI3pVqikRO1 for <tcpm@ietfa.amsl.com>; Tue, 3 Aug 2021 21:38:38 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257C83A09D8 for <tcpm@ietf.org>; Tue, 3 Aug 2021 21:38:37 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id j1so1230562pjv.3 for <tcpm@ietf.org>; Tue, 03 Aug 2021 21:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZIkp85ARvYRX5j9ScderQnB/wzDqsasMg1BM4IU41mU=; b=cdN8I2PrKGCHNFMBHMIMNRE68eAaTMDGBbJ9/Ffx/9CnVsYT0sxand3m7bzI2ozM/6 8LRFPkXo2N9w3mrXy5hmzxJMts+s/UzyYm2i+saU3/8uv7faT7lb9wnSNUBfkIWZqPxF 237ZLf1W8JZdsX2l8dtqK0/pSeorbDxHr1zQXQcC8JvjuIuRS0V0GdiHdrEie41+LUBH EccZgDMKROl+3eGo8si+2YARO8ERYVoeXmRzdR3+1fXNQE6Dn3/lL1We6p/zNZykBjnk gPXHBDQ+OeVxEVE/6TRbHcLUYEJMwlrZ1hdT7Bi1OLHLN5vI5q7WZDreSu1OlZ+4a5ED Y6Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZIkp85ARvYRX5j9ScderQnB/wzDqsasMg1BM4IU41mU=; b=Xxv/AG0ab+89mfH2BobFxyKjOnMGVQOOB1Us4Kr5oknwGPNZcVB6uO/nxKqTQxl4OJ Js2Gfdp+IVy+vChg+iojxmMQj23qtpH6M1tAQCEeeke5FoMQmDlnTEg2UyvFC6CZitkF TZMAL9NHD3RI1L7i/BuNpcM3vkRXPMqrxrBOAtuDrRqOh6tMbOj5536T3EMIinrLLgaN Hflgl2aQYF+sXp52hhW2XQWdEVHDDyAGPuJ73hrMzhj8MGQRrB8jTxv1FgTFREO3N9J7 bBiPU66YZNNXWSuhxzFp/G/NuedgsNKBFQ/0tHfy3DERQFCUefyE4IZZf7RSE4QK3wwD oviw==
X-Gm-Message-State: AOAM53061iqxX684/Zf9H0ADvFVVrlme6He+z4YkICIRyD5HSBu9v/Xy Ups9haGSjWAxHKOgs28eV5CmNg5/5/i3eTTukzuuR/1nnf4=
X-Google-Smtp-Source: ABdhPJzIgZ0oCr4UTzzM7XlJbvqq6Y/zF9gAwBPLPAvR2b9ne77jxFlIIvOBfRPxu8bzYsRyQjw7yXK1A8qaWjWhetg=
X-Received: by 2002:a05:6a00:1713:b029:332:7eca:41a1 with SMTP id h19-20020a056a001713b02903327eca41a1mr25627415pfc.26.1628051916895; Tue, 03 Aug 2021 21:38:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAKz0y8x2NWLE1Nzmah5iwvbFRCh3YrMpGU6seudJZMWCJeOE2Q@mail.gmail.com> <E34B0D3E-8574-480C-B1B6-A5B33B1808D8@strayalpha.com>
In-Reply-To: <E34B0D3E-8574-480C-B1B6-A5B33B1808D8@strayalpha.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Wed, 4 Aug 2021 10:08:25 +0530
Message-ID: <CAKz0y8yrL4bU3jAqPkgU+ZRNCq4bTzaOwgpD-cca3SLzzLs8xQ@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002eb95105c8b460f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/5lgA5O7yH8HZhai-2y3J5B1GUlw>
Subject: Re: [tcpm] Question on crypto algo usage for TCP-AO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2021 04:38:43 -0000

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
>
>
>