Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

"Adam Langley" <> Tue, 15 July 2008 02:04 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 19F633A68A0; Mon, 14 Jul 2008 19:04:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55AA3A68A0 for <>; Mon, 14 Jul 2008 19:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wmoRxz771Kyy for <>; Mon, 14 Jul 2008 19:04:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D2C313A67EC for <>; Mon, 14 Jul 2008 19:04:31 -0700 (PDT)
Received: by with SMTP id b25so4473433rvf.49 for <>; Mon, 14 Jul 2008 19:04:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=3eUQK3XAbfmo9ZPp5bYzfpq1gfqSFfR+wnYG+ts3kF4=; b=Z8BXYrnDFAH+BDYiJXc+fFdYULkeEG9UrEoeRdRnQa3HwnuCzDNIZk5iEF+YSaGUSa pzhIMxqDpvIN+86QR2BQWXudF0QlloJ2YutUWlqFwCXVXE+f6caZDChpP2NWK14uBCzj wQqX/FHWrt1CradhWCyN/EGLxhSwoQ25aO/SU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=QYNWw08p314SJlqzMwur6xZRQUD+SHJ8gw8FS1SO/1yxUg0Rv9GK5fc5YNJ0VLwGqw 1/Oom6lWt7/tK3CFX3faiPxIJmIrf0lBFfBA/E8ppLYb8D3ycLjBjZbxAPUwO13SLyhH +yX0dSA4sxUBE0IGsUJvc94AZMWLh2wqYaF/o=
Received: by with SMTP id u15mr5431662rvn.51.1216087498517; Mon, 14 Jul 2008 19:04:58 -0700 (PDT)
Received: by with HTTP; Mon, 14 Jul 2008 19:04:58 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2008 19:04:58 -0700
From: Adam Langley <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <>
X-Google-Sender-Auth: 9c82ff79fcac365f
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

2008/7/14  <>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>        Title           : The TCP Authentication Option
>        Author(s)       : J. Touch, et al.
>        Filename        : draft-ietf-tcpm-tcp-auth-opt-01.txt

Going by the changes section:

> requiring an algorithm for nonce introduction based on ISNs"
> The presence of TCP's pair of
>   Initial Sequence Numbers presents a nonce that may be useful in that
>   case. Such a nonce could be computed as the concatenation of the ISNs
>   (initiator, responder), and the socket pair (addresses, ports):

>   o  Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r

I'd like to step back and review this for a moment:

We have a couple of reasons for wanting to define an nonce:

Reason 1: Without a monotonic counter, a MAC is open to replay
attacks. I'm not sure how serious this is. Certainly you can elicit
different behaviour from stacks by replaying, say, an ACK very
quickly. This is undesirable, but it might be acceptable. More
troubling is the possibility of exploiting sequence number rollover to
inject a valid packet from 2^32 bytes in the past into the current
stream. A monotonic nonce would mean that we could reject replays.

Reason 2: Some MAC functions require an nonce as an input and their
security depends on the nonce never being reused for any other message
with the same key. Consider a connection where all the
application-level data transfer is one way and a packet, seq number n,
is lost by the network. Here, it's very possible that an ACK for n-1
is transmitted, followed by an ACK for n-1 with a SACK option. Now
we've transmitted two different messages with the same nonce. Any
nonce based only the sequence numbers has this problem unless we
disable/don't include SACK. Also, if we are only including 32-bits of
seq, then we trivially repeat every 2^32 bytes.

The suggested nonce scheme, above, thus doesn't suffice for reason 2.
However, since the ISNs and pseudoheader are already included in the
MAC's input, it doesn't do anything for reason 1 either. I don't
believe adding in the IP ID would help either.

Option 1: don't define an nonce, accept the reply-attack implications
and disallow MACs which require strong nonces

Option 2: define a 64-bit message counter in each direction, include
the bottom n-bits in the AO option and allow some small amount of
reordering. Reject duplicate messages. This solves reasons 1 and 2 but
requires extra option data and extra state.

Option 3: use the seq number as the bottom 32-bits of a 64-bit
sequence. It solves replay attacks after 2^32 bytes, but not some
other replay attacks. It doesn't solve reason 2. It involves extra
state. However, if options are not included in the message, then this
*does* solve reason 2 I suspect. I'd want some wiser minds to confirm
this however.

Option 2 is the cryptographically strong solution. Consider the
options in a packet:
  10 bytes of timestamp option
  18 bytes of AO (96-bit MAC + 2 bytes of option header + key id + nonce)
  12 bytes remaining (enough for one SACK block)

If the key id was only a bit, then we have 31 low bits of message
counter. That's acceptable I think. It would require a packet loss
burst of 3^30 packets to de-sync the hosts (which implies a window of
> 1 TB @ 1500 MTU). It's really cramming things, however and the
storing the counter-space holes to allow for reordering might become
expensive if the reorder window is large.

So, although I like option 2, any of them would be ok. But I think the
current wording in the spec needs to be clearer about which we're

> Clarify NAT interaction

I do believe that some method of getting through common NATs (other
than wrapping the packets in a tunnel) is needed. There was my
previous suggestion of making pseudo-header inclusion optional and
having userspace specify a 20-byte bit mask, which is applied to the
TCP header (I'll concede that it's a painful 20-bytes of extra state).
Alternatively, the common case can be specified with a single bit to
remove the pseudo-header and port numbers from the MAC's input.


Adam Langley
tcpm mailing list