Re: [karp] Call for WG adoption: draft-mahesh-karp-rkmp-04

Joe Touch <touch@isi.edu> Mon, 29 July 2013 16:03 UTC

Return-Path: <touch@isi.edu>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C914D21F9655 for <karp@ietfa.amsl.com>; Mon, 29 Jul 2013 09:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs0SbVrNCNNH for <karp@ietfa.amsl.com>; Mon, 29 Jul 2013 09:03:38 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 76BC321E808E for <karp@ietf.org>; Mon, 29 Jul 2013 09:03:36 -0700 (PDT)
Received: from [192.168.1.91] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r6TG2o02024446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Jul 2013 09:03:01 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset=us-ascii
From: Joe Touch <touch@isi.edu>
In-Reply-To: <tslehahydua.fsf@mit.edu>
Date: Mon, 29 Jul 2013 09:02:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <41256376-6143-4236-A9B0-19BFE022E049@isi.edu>
References: <51F6173E.70007@joelhalpern.com> <19780515-2383-452C-B1E8-33CB033AA2D6@vigilsec.com> <tslehahydua.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.1508)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "karp@ietf.org" <karp@ietf.org>
Subject: Re: [karp] Call for WG adoption: draft-mahesh-karp-rkmp-04
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 16:03:49 -0000

On Jul 29, 2013, at 1:23 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:

>>>>>> "Russ" == Russ Housley <housley@vigilsec.com> writes:
> 
>    Russ> I am confused by the approach taken in this draft.  I only
>    Russ> skimmed it.  We defined a crypto key table, and that document
>    Russ> is close to IESG approval.  I think that IKEv2 should be used
>    Russ> to populate the key table, and then TCP-AO can pull keying
>    Russ> material from the table, as is already described, at least
>    Russ> partially, in the key table document.  Russ
> 
> RKMP is intended to work with the key table draft as you describe.
> With the specific case of TCP-AO there are some additional complexities
> because of abstractions created by the TCP-AO spec.

The complexities are at least partly related to the fact that IKE is based on network (IP) protocols and sequences of streams using the same ports, whereas TCP-AO never reuses connection keys on successive connections to the same ports.

The complexities are non-trivial, and require the introduction of a new mechanism to translate between the expectations of IKE and TCP-AO. draft-mahesh-karp-rkmp describes this mechanism in detail.

> It's certainly intended to be the case that rows are added to the key
> table by RKMP and it's intended to be the case that TCP-AO interacts
> with the key table in a manner similar to how it handles manual keying
> with regard to RKMP.

draft-ietf-karp-crypto-key-table describes some very limited ways in which RKMP might interact with TCP-AO, but those limitations are severe - using one key across all interfaces, e.g. At best, crypt-key-table is dismissive in its support for TCP-AO; at worst, it gives recommendations that could be ill-advised.

This document (draft-mahesh-karp-rkmp) provides a specific mechanism to more completely interface TCP-AO to IKE, where that mechanism compensates for the different assumptions of TCP-AO and IKE regarding connection and key usage. 

(note that mahesh-karp does refer to crypto-key-table, but it adds significantly to it)

Joe