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

Joe Touch <> Mon, 29 July 2013 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C914D21F9655 for <>; Mon, 29 Jul 2013 09:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.299
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zs0SbVrNCNNH for <>; Mon, 29 Jul 2013 09:03:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 76BC321E808E for <>; Mon, 29 Jul 2013 09:03:36 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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 <>
In-Reply-To: <>
Date: Mon, 29 Jul 2013 09:02:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Sam Hartman <>
X-Mailer: Apple Mail (2.1508)
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>
Subject: Re: [karp] Call for WG adoption: draft-mahesh-karp-rkmp-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jul 2013 16:03:49 -0000

On Jul 29, 2013, at 1:23 AM, Sam Hartman <> wrote:

>>>>>> "Russ" == Russ Housley <> 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)