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

Sean Shuo Shen <sshen@huawei.com> Mon, 07 January 2008 12:44 UTC

Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m07Ci91O015407 for <saag@PCH.mit.edu>; Mon, 7 Jan 2008 07:44:09 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m07ChxpT003314 for <saag@mit.edu>; Mon, 7 Jan 2008 07:43:59 -0500 (EST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mit.edu (Spam Firewall) with ESMTP id 80B10D1AF60 for <saag@mit.edu>; Mon, 7 Jan 2008 07:43:36 -0500 (EST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU900A8QY0KBU@szxga01-in.huawei.com> for saag@mit.edu; Mon, 07 Jan 2008 20:43:32 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JU9007PTY0JG1@szxga01-in.huawei.com> for saag@mit.edu; Mon, 07 Jan 2008 20:43:31 +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 <0JU900CRIY0F0H@szxml04-in.huawei.com> for saag@mit.edu; Mon, 07 Jan 2008 20:43:31 +0800 (CST)
Date: Mon, 07 Jan 2008 20:43:27 +0800
From: Sean Shuo Shen <sshen@huawei.com>
In-reply-to: <477FB4E6.4030507@isi.edu>
To: 'Joe Touch' <touch@ISI.EDU>
Message-id: <000601c8512a$e6785060$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: AchPuuoXYxsXIcERShWEt2RG5G0EgABZi98g
X-Spam-Score: 3.5
X-Spam-Level: *** (3.5)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, cfrg@ietf.org
Subject: Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://mailman.mit.edu/mailman/listinfo/saag>, <mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/saag>
List-Post: <mailto:saag@mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Subscribe: <http://mailman.mit.edu/mailman/listinfo/saag>, <mailto:saag-request@mit.edu?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 12:44:09 -0000

Hi Joe,

>Please indicate the proof for this. First, it requires that the rest of
>the system enforce the "no reuse of keys during seqno rollover"; second,
>it requires that TCP implementations not allow the socket data to change
>between initial transmission and retransmission.
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.

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. So I did not
require that TCP implementations not allow the socket data to change between
initial transmission and retransmission.
Regards

Sean