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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 2BFBD3A6881; Mon, 14 Jul 2008 21:58:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B51823A6881 for <>; Mon, 14 Jul 2008 21:58:15 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9YWrk1bg519 for <>; Mon, 14 Jul 2008 21:58:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D452D3A67D1 for <>; Mon, 14 Jul 2008 21:58:14 -0700 (PDT)
Received: by with SMTP id b25so4510680rvf.49 for <>; Mon, 14 Jul 2008 21:58:41 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6hLb4kLN64Jd1utPIpk0d9Xvb+rIT0n6vISGTH7eum0=; b=nS+M1L3MTcvAzaXuPx6EmwXo7ru1nnNmrNtR2JKQQJ8KzVH7yJD3Hmr6Cw841PgojW oj1rr17MFWd/deTIQ+TKFu/JSujj/64xKeyVbAqX8uWCBPw4/hOs4CmUimiICntPYHIZ lwYykMUf+FvVeHqg6awmUnO5Tf0E5xINz0puo=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=VZbQbk3+s3UQtlkLkVqkrwBxkXsfy1YlP/pwnwlekSj9UaB1F2hqm3jljRLIZVWq4n H1ryU8zwUSfhmclJO7aXLQ14wrNqtvPQtKEa37jiI5gzNp+E7Shv2bVB6E/xAntDh/BU GRYO7izmpql2VPhzINZ1joOe3uBlD5kQ/h3v0=
Received: by with SMTP id r19mr7113624rvm.146.1216097921637; Mon, 14 Jul 2008 21:58:41 -0700 (PDT)
Received: by with HTTP; Mon, 14 Jul 2008 21:58:41 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2008 21:58:41 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <>
X-Google-Sender-Auth: 1801ddf90d907fd9
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

On Mon, Jul 14, 2008 at 8:33 PM, Joe Touch <> wrote:
> The nonce is for generating per-session keys, not for per-packet operations.
> Per packet uniqueness is discussed in the replay section of the Security
> Considerations, and is governed primarily by the TCP sequence number, and
> the strong suggestion (elsewhere) to change the key every 2^31 bytes if
> uniqueness is a concern.

Right, sorry I misunderstood that.

> Option 4 is what we currently suggest, which is:
> use the 32-bit sequence number as the per-packet nonce, and encourage
> rekeying every 2^31 bytes or so.

Ok. That's what I called option one,

>        - it still provides a nonce (I don't see how to "disallow"
>        MACs that require a nonce. I don't know what a "strong"
>        nonce is, though - nonce just means unique. If 'strong'
>        means 'random', that's different (i.e., entropy inducer,
>        vs. just unique).

Some MACs accept a pair as their input (M,n) where n is a strong
nonce. These MACs require that a given nonce, n, never be used with
two different messages. If you do, then you may well be exposing key
information etc (the security proof is invalid so anything's
possible). Since we can't guarantee this, we just have to exclude them
I believe. Since the well known MACs (MD5, SHA family etc) are not of
this type it's not a big issue.

> I prefer including the expected addrs and port numbers for the following
> reason:
> 1. TCP-AO needs to know what the addr/port pair is at the receiver behind
> the NAT anyway in order to match keys to connections

Only in the case where a listening socket is configured with a list of
(source, key) pairs. That's the case with routers and BGP sessions
etc, but one could certainly imagine TCP-AO as a (better) alternative
to port-knocking schemes. Also, it doesn't work for connections where
the AO key is established by the application level after the TCP
handshake. (Although, in the latter case, one could argue that each
host should tell the other its NAT translated identity just to make AO


Adam Langley
tcpm mailing list