Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

Eric Rescorla <ekr@networkresonance.com> Mon, 28 July 2008 18:09 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2F928C2A7; Mon, 28 Jul 2008 11:09:03 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6049C28C2A7 for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 11:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8mFnLCQFWU4 for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 11:08:57 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id F318E28C0FB for <tcpm@ietf.org>; Mon, 28 Jul 2008 11:08:56 -0700 (PDT)
Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 22EC04BA1D7; Mon, 28 Jul 2008 11:09:07 -0700 (PDT)
Date: Mon, 28 Jul 2008 11:09:07 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <488E0644.6020006@isi.edu>
References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <488E0644.6020006@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080728180907.22EC04BA1D7@kilo.rtfm.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
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

At Mon, 28 Jul 2008 10:47:48 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Eric,
> 
> Eric Rescorla wrote:
> ...
> |> OK; we're dancing around terms here. TCP-AO uses a _separate_ document
> |> to specify the out-of-band key mechanism. What that includes can be
> |> discussed in that context - e.g., on SAAG.
> |
> | Well, I think that's a mistake as well.
> 
> That's outside the scope of this document; that was handed to the design
> team as a requirement of this work. Perhaps the ADs should address the
> reasons directly.

Well, to the extent to which this was an instruction from the
AD, I think this should be reconsidered.


> |     The second needs to be tied to the transport protocol. The
> |     first is replaceable. The problem here is that you have
> |     merged them and treated them both as separate. That's problematic.
> 
> Are you saying that we generate per-session keys inside TCP-AO?

Per-connection keys, yes.

> |> | Sure. You have a per-connection key. Every time the sequence number
> |> | rolls, you run the KDF again to generate a fresh per-connection key.
> |> | No KMP required. (This meshes with my previous key diversification
> |> | comments).
> |>
> |> That's burying the key generation protocol inside TCP-AO.
> |
> | Again, key generation != key establishment.
> 
> Agreed, but there is utility in keeping TCP-AO clean from algorithmic
> crypto issues.

Perhaps, but there's also utility in having a single, complete,
spec.

> | The protocol must be constructed so that it is not possible to substitute
> | one packet for another and have it be accepted. This means that (either)
> | the data fed into the authentication function must be distinct or the
> | authentication function must have a distinct key.
> 
> That implies a per-packet nonce, i.e., some fields - either in the
> packet or external - that are unique on a per-packet basis.

Well, perhaps we're just differing in terminology, but I don't call
per-packet data fed into the authentication function a nonce. 
I think of the nonce as a discrete value, not just the data.
But in this case we're just talking about MACing the packet.

I just checked and neither AH nor TLS uses the term nonce here.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm