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

Joe Touch <touch@ISI.EDU> Sat, 05 January 2008 16:49 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 m05GnlDS019831 for <saag@PCH.mit.edu>; Sat, 5 Jan 2008 11:49:47 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m05GnbOA013494 for <saag@mit.edu>; Sat, 5 Jan 2008 11:49:37 -0500 (EST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 90A3FCAD13D for <saag@mit.edu>; Sat, 5 Jan 2008 11:49:16 -0500 (EST)
Received: from [192.168.1.44] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m05Gmdqg010561; Sat, 5 Jan 2008 08:48:40 -0800 (PST)
Message-ID: <477FB4E6.4030507@isi.edu>
Date: Sat, 05 Jan 2008 08:48:38 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Sean Shuo Shen <sshen@huawei.com>
References: <006401c84f66$83665780$350c6f0a@china.huawei.com>
In-Reply-To: <006401c84f66$83665780$350c6f0a@china.huawei.com>
X-Enigmail-Version: 0.95.5
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigCDC0E181C501E94CFFC293C0"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.00
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: Sat, 05 Jan 2008 16:49:47 -0000


...
>> If there were no assumption, then I would agree, but the above indicates
>> a clear assumption that we cannot clearly ensure.
> Ok we discussed:
> nonce=PRF(key, index) . 
> index =segment length + tcp header without dport&sport. The index can
> include all the tcp header including options, but the fields (like port
> numbers) that won't change within a connection can be omitted, fields that
> are set to be zero in mac culculations can also be omitted.
> The problem is:
> In a tcp connection, before a seqnum rollover (when rollver happens, both
> hash key and PRF key need to be renewed), index must be different when the
> authenticated content described in tcpm-tcp-auth-opt-00 is different. Hence
> the calculation nonce=PRF(key, index) will give different values.
> Proof: 
> When the authenticated content changes, there are just two cases: seqnum
> changes or not. 
> If seqnum changes the index changes.
> If seqnum does not change, segment length either changes or not:
> 	If segment length changes, index changes;
> 	If segment length does not change, changes can only come from TCP
> header
>  	including option, in this case, the index also changes.

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.

Although I wouldn't think such data changes would be useful, I wouldn't
want to require FIPS validation of that property, since it creeps down
into the socket layer.

Joe