[secdir] draft-ietf-karp-crypto-key-table-07

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Fri, 19 April 2013 14:05 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7D98521F8A74; Fri, 19 Apr 2013 07:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XoggpHD8GZkU; Fri, 19 Apr 2013 07:05:24 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id D0E0A21F875C; Fri, 19 Apr 2013 07:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2553; q=dns/txt; s=iport; t=1366380324; x=1367589924; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=FdC+aAnrENtFyHY/j86zDpzYZl11Wx8II+89JhvTPj0=; b=K/zrHF0ifPd0b4DpzAQI2njdrGxK76vk7sAvFxl6sCoWWpHNXS4WNrTA Pggrg2tUM5FEYI+xyB3AYPy1MzKAUfNuchrUlfaLgnjumdOG+N96YenX0 tI+o1f8k5XAIXvvr4lqml5RkyfWxPckOEb6pwQBrbkorUU2jtr1X9Fock g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208";a="200680926"
Received: from rcdn-core2-5.cisco.com ([]) by rcdn-iport-2.cisco.com with ESMTP; 19 Apr 2013 14:05:23 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com []) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3JE5NVj028161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 14:05:23 GMT
Received: from xmb-aln-x12.cisco.com ([]) by xhc-rcd-x08.cisco.com ([]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 09:05:22 -0500
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" <draft-ietf-karp-crypto-key-table.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: draft-ietf-karp-crypto-key-table-07
Thread-Index: AQHOPQbuce+OHU+sDECZBdq2jRPubA==
Date: Fri, 19 Apr 2013 14:05:22 +0000
Message-ID: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EA41D38C693B3E42A412BA52B1C685E9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] draft-ietf-karp-crypto-key-table-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2013 14:05:24 -0000


I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document is clear and easy to understand. I have a few comments/questions though:

* 1 Intro

What is conceptual about it? Isn't this supposed to be a specification of the format for a real database?

At this stage it is unclear to me where the database should reside, under control by whom etc.

* 2 Conceptual Database Structure

introductory paragraph: it is hard to grasp why or why not you want to have the same key appear twice without understanding what the format of the database will look like. So I think you should move that part of the first paragraph to below the column definition.

Peers: hmm, so now you have a multivalued column of arbitrary length? What is the separator? And do you expect normalisation into separate tables to happen?

Protocol: So here you want only a single security protocol, resulting in rows with the same key but different protocols. Resulting in a more complex lookup but no normalisation into separate tables necessary, I'd say best to choose one solution and stick to it. 

Sendlifetimestart: I don't see the need for the Z if you already specify that the format is UTC

* 3 Key Selection and Rollover

Do you only want to leave the choice of algorithm/ciphersuite to the client? How about including a preference in case of multiple entries for the same key? 

I understand the reason to select the latest SendLifeTimeStart, at the same time, if I want to minimise roll-over I might want to select the key with the latest AcceptLifeTimeEnd

I am wondering whether it makes a lot of sense to separate Send and Accept LifeTime, I can come up with some constructed examples  but I wonder how common that is, isn't it more typical to stop sending when you don;t want the peer to accept anymore, i.e. send=accept Lifetime?

* 7 Security Considerations

I would expect some wording on access to the database, whether the database is shared etc. The database seems an extremely interesting attack vector to me, basically by gaining write access to the database I control the security policy for the communication between the two peers.