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

Joe Touch <touch@ISI.EDU> Mon, 28 July 2008 17:48 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 DA8F83A69E4; Mon, 28 Jul 2008 10:48:39 -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 3D97F3A69BF for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 10:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599]
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 6cul7ozANxDF for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 10:48:34 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C6FE3A69EB for <tcpm@ietf.org>; Mon, 28 Jul 2008 10:48:34 -0700 (PDT)
Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SHmJ0Z015656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 10:48:23 -0700 (PDT)
Message-ID: <488E0644.6020006@isi.edu>
Date: Mon, 28 Jul 2008 10:47:48 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
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>
In-Reply-To: <20080728164013.422D14B9600@kilo.rtfm.com>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

-----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.

| (2) There are two issues:
|
|     - What's used to establish an association and keying material
|     - How that association and keying material get turned into
|       per session keying material.
|
|     In IPsec with IKE, the KMP is run for every new association
|     and so these end up specified in a separate document as
|     a single entity. However, in this case, because people don't
|     want a separat KMP run for each association, these are separate.

I'm not sure this is the case...

|     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? We
attempted to split the TCP-AO/key issue in a particular place; if
there's a better place to split (e.g., burying the ISN stuff in the
TCP-AO side), it might be useful to hear more...

My concern is that the point of the key system is to decouple potential
changes to session keying from the option side. All the crypto-related
info should stay on the keying/MAC side of the house if at all possible,
i.e., external to TCP-AO.

| (3) SAAG has no capability to work on anything, and isn't doing so.

Tim Polk spoke to that issue; he said we'd see something this fall.

|> |> | The TCP authentication protocol should be able to provide
security for
|> |> | packets even in the face of sequence number rollover, out to the
|> |> | limits of security of the MAC algorithm (which far exceed 2^31 bytes
|> |> | in both cases). There are (at least) two potential approaches:
|> |> |
|> |> | 1. Use a (synthetic) extended sequence number.
|> |>
|> |> We discussed this, but there are concerns with interactions with
TCP. We
|> |> don't want to add separate, coordinated state outside the existing TCP
|> |> state mechanism.
|> |
|> | Uh, ok... It's not like this doesn't need to be tightly coordinated
|> | with TCP in any case.
|> |
|> |
|> |> | 2. Change the key used to compute the MAC inside the protoco.
|> |>
|> |> Can you explain this?
|> |
|> | 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.

|> |> | But I don't think it's a good idea to punt this to the KMP, since
|> |> | you don't really need to change the key for any cryptographic
reason.
|> |>
|> |> If there's no cryptographic reason, why would we need to change
the key
|> |> at all? I.e., isn't the need for a unique per-packet nonce a
|> |> cryptographic requirement (if not, why do we care?)
|> |
|> | There is no need for a unique per-packet nonce.
|>
|> If so, then why generate fresh keys on rollover?
|
| 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.

| I wouldn't call this
| a "nonce" in either case, and I don't know what a "per-packet nonce"
| means. We're talking about the connection and packet parameters.

I think this is a per-packet nonce, at least as I understand it. As I
noted, that can be handled by the rekeying system.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiOBkQACgkQE5f5cImnZruV1ACeJYsf3Fii9DK8p61shBGPg4Rc
h+QAoO9cJwsuakk8fsvg5KbklGy/z25Z
=n6A1
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm