[tcpm] draft-ietf-tcpm-tcp-auth-opt-00

"Adam Langley" <agl@imperialviolet.org> Tue, 01 July 2008 17:45 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 241E73A6B99; Tue, 1 Jul 2008 10:45:40 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id B943B3A6B99 for <tcpm@core3.amsl.com>; Tue, 1 Jul 2008 10:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id cKc9OE5kzgdR for <tcpm@core3.amsl.com>; Tue, 1 Jul 2008 10:45:37 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com []) by core3.amsl.com (Postfix) with ESMTP id A57303A6784 for <tcpm@ietf.org>; Tue, 1 Jul 2008 10:45:37 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1750502rvf.49 for <tcpm@ietf.org>; Tue, 01 Jul 2008 10:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=9ro0LVpya/FkbX/L6WF+gPkXV4UMlXGZ/mP9HLIveJc=; b=HWXOg3glUfbc36Dq4PKH6CDI7lSIaTSu98ZkKegFlhEOe9c0sRVLuxQcoCbitxdXlF hS3AlXASZJ9jp0pSywNbCe56izkijBNC7mTaLy+wYGAkgMN7VHsAgj3px+SZhkP0LsM3 MrJ4x+VBPolFlaT5bikTMtk7ikd2EO+AmVhHA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=sZ+QqO8H9NReoMznRyDuPo7jQdrt8ZNrQKRwa9Cj6VdENApTfeHUDM1mm/MxCTBK9I /v4NuCDEZ3uYPGkg5E8setJ/tB6qGh9OxB2i8ILd2Xq9W8jCX6S4L00lTEMOAMJKoSxP aglQ0k59uWqrwaU5rupZQUJEHlXL623NsJzeA=
Received: by with SMTP id x16mr3777851rvf.120.1214934348351; Tue, 01 Jul 2008 10:45:48 -0700 (PDT)
Received: by with HTTP; Tue, 1 Jul 2008 10:45:48 -0700 (PDT)
Message-ID: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com>
Date: Tue, 01 Jul 2008 10:45:48 -0700
From: Adam Langley <agl@imperialviolet.org>
To: tcpm@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
X-Google-Sender-Auth: 9c5a367d19511aec
Subject: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

> 2.2. TCP-AO Option


> The MAC is computed over the following fields in the following order:

Currently AO is suggesting the same serialisation as TCPMD5:
  sig = MAC(key, pseudoheader + header + data)

I suggest, instead, that the default serialisation be:
  sig = MAC(key, H(data) + pseudoheader + header)

When the TCP stack is getting data from userspace, it generally knows
the MSS and splits the data into packets right away. With the
suggested serialisation, the data can be hashed as it's copied and the
hash stored with the data. This saves traversing the data again at
transmit time to calculate the MD5 signature. The latter is no less
secure, I believe, and opens up possibilities for optimisation so
should be a clear gain.

Note that MAC(key, H(data) + pseudoheader + header) is better than
MAC(key, data + pseudoheader + header) because, with the latter, a
partial block needs to be stored as well. With common hash functions
(MD5, SHA-1) this is 64-bytes of extra data.

Additionally, the draft already mentions an Option Kind Exclusion List
and I'd suggest another option: that the pseudoheader be omitted and
the source/destination ports in the TCP header be zeroed. This would
allowed the signature to be robust to most (all?) NATs. The NAT
workaround suggested in section 7 is impractical for many uses and a
significant fraction of hosts are now imprisoned behind NATs.

Currently unspecified is a nonce for the packets. Modern MAC
functions, based on polynomials (such as [1]), can have the very
pleasing property of being provably within a factor as secure as
another function (like a block cipher). However, they often require
nonces as inputs.

A trivial solution would be to keep a 64-bit counter, increment it for
each transmission and transmit it along with the signature. However,
we'll struggle to fit that all in the options space; esp for SYN
packets. Next we could consider taking the seq number as the lower
32-bits of a 64-bit counter. However, that doesn't guarantee that two
different messages wouldn't be transmitted with the same nonce. We
could just transmit the bottom (say) 16-bits of the nonce, but a
prolonged outage could knock the endpoints out of sync. I don't have a
good solution here.

Also, is encryption of the payload considered out-of-scope for this spec?

[1] http://cr.yp.to/mac.html

Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
tcpm mailing list