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
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms mcgrew
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Stephen Kent
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Steven M. Bellovin
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Steven M. Bellovin
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Stephen Kent
- Re: [saag] TCP-AO MAC algorithms Brian Weis
- Re: [saag] TCP-AO MAC algorithms Eric Rescorla
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Joe Touch
- Re: [saag] [Cfrg] Re: TCP-AO MAC algorithms Sean Shuo Shen
- [saag] Managing aglorithms RE: TCP-AO MAC algorit… Hallam-Baker, Phillip
- Re: [saag] Managing aglorithms RE: TCP-AO MAC alg… Vishwas Manral