RE: [saag] [Cfrg] Re: TCP-AO MAC algorithms

Sean Shuo Shen <sshen@huawei.com> Tue, 08 January 2008 00:44 UTC

Return-path: <cfrg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC2aP-00062x-0A; Mon, 07 Jan 2008 19:44:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC2aN-0005s7-W0 for cfrg@ietf.org; Mon, 07 Jan 2008 19:44:56 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC2aL-0003uH-Jb for cfrg@ietf.org; Mon, 07 Jan 2008 19:44:55 -0500
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUA004I3VDU45@szxga02-in.huawei.com> for cfrg@ietf.org; Tue, 08 Jan 2008 08:44:18 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUA00IAFVDURN@szxga02-in.huawei.com> for cfrg@ietf.org; Tue, 08 Jan 2008 08:44:18 +0800 (CST)
Received: from s102542 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUA008K9VDQDA@szxml04-in.huawei.com> for cfrg@ietf.org; Tue, 08 Jan 2008 08:44:18 +0800 (CST)
Date: Tue, 08 Jan 2008 08:44:14 +0800
From: Sean Shuo Shen <sshen@huawei.com>
Subject: RE: [saag] [Cfrg] Re: TCP-AO MAC algorithms
In-reply-to: <47823D3D.1010001@isi.edu>
To: 'Joe Touch' <touch@ISI.EDU>
Message-id: <001f01c8518f$97c6cae0$350c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AchRPYU4UeOgjgnWSEaVda7pz8s/5QAUBaAg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: saag@mit.edu, cfrg@ietf.org
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Errors-To: cfrg-bounces@ietf.org

>> First, I remember somewhere it is said that the MAC key should be renewed
>> when sequence number rollover, in your first email you also mentioned
that
>> "This is why we probably need to explicitly require that the connection
key
>> change whenever the sequence number rolls over (through the ISN)." I
believe
>> you are giving a reasonable and achievable requirement (hash key renewing
>> during rollover). If hash key renewing during rollover is doable, nonce
key
>> renewing during rollover is also doable and it's not an extra
requirement.
>> The way to renew keys is out of the scope of our discussion. I don't
think
>> we have to give a key management scheme before talking about MAC
algorithms.
>It all depends on whether key reuse during rollover is prohibited 
>outright or just recommended against. If the former, I agree it's 
>sufficient to roll over the nonce key at the same time. It's the latter 
>case that's the issue, and whether to make this something FIPS 
>certification relies upon.
Key reuse during rollover is prohibited.

>> Second, maybe there is a misunderstanding here. What I mean is: the nonce
>> generation algorithm can guarantee that nonce is different when the MAC
>> protected data are different (because some mac algorithms require
different
>> nonce when hashing different messages). If the MAC protected data (I
assume
>> this is what you mean by "socket data") are same between transmission and
>> retransmission, it is totally fine for nonce to be same.
>That depends on whether the nonce is used to provide replay protection.
>If it is, then it can't be the same if the entire segment is the same.
The nonce here is not used against replay attack. 

Sean



_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg