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

Eric Rescorla <ekr@networkresonance.com> Mon, 28 July 2008 16:40 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 E7C5B28C10C; Mon, 28 Jul 2008 09:40:04 -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 A557528C10C for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 09:40:03 -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 kOGH3NFAVw6h for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 09:40:02 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id 6F62E3A6915 for <tcpm@ietf.org>; Mon, 28 Jul 2008 09:40:02 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 422D14B9600; Mon, 28 Jul 2008 09:40:13 -0700 (PDT)
Date: Mon, 28 Jul 2008 09:40:13 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <488DE021.7070307@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>
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: <20080728164013.422D14B9600@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 08:05:05 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Eric Rescorla wrote:
> ...
> |> | Regardless of whether there is a KMP, it strikes me as unwise to
> punt this
> |> | job to it.
> |>
> |> There is a KMP; it is required (and we can't move forward to submit this
> |> as final until there is).
> |
> | Well, as I've indicated previously, I don't agree that a KMP is
> | required or desirable. It's quite straightforward to make this system
> | work with a single, pairwise, static key, provided you have an
> | appropriate key diversification mechanism. If you want to call that a
> | KMP, I suppose you could, but since it doesn't require actually
> | exchanging any messages, I would not do so.
> 
> 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.

(1) It's extremely confusing to have two documents.
(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.
    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.

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


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


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

-Ekr


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