Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08

Sam Hartman <hartmans-ietf@mit.edu> Wed, 14 August 2013 19:31 UTC

Return-Path: <hartmans@mit.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 CDF3221E808C; Wed, 14 Aug 2013 12:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level:
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 8VZudT0fEjn7; Wed, 14 Aug 2013 12:31:53 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE921F99D0; Wed, 14 Aug 2013 12:31:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9212A20280; Wed, 14 Aug 2013 15:30:41 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLmALA9OwzD7; Wed, 14 Aug 2013 15:30:41 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 14 Aug 2013 15:30:41 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3D9D48051A; Wed, 14 Aug 2013 15:31:50 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: "Black\, David" <david.black@emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com>
Date: Wed, 14 Aug 2013 15:31:50 -0400
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> (David Black's message of "Fri, 9 Aug 2013 10:47:05 -0400")
Message-ID: <tslr4dwcbmh.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "ietf@ietf.org" <ietf@ietf.org>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "karp@ietf.org" <karp@ietf.org>
Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
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: Wed, 14 Aug 2013 19:31:59 -0000

>>>>> "Black," == Black, David <david.black@emc.com> writes:


    Black,> [A] Overall - I would like to see a paragraph added on how
    Black,> this database conceptually relates to the IPsec Peer
    Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3.

It doesn't.
not even a little bit.
It's not IPsec; it's not about what key management peers to interact
with.

It's conceptually similar to the Security Association Database (SAD).
In a discussion with Jari I agreed to propose text for a paragraph
describing how this interacts with IPsec.

If this conceptual database is used to manage to keys for a security
    protocol that uses IPsec [RFC4301] security services, then  the
    interactions between this conceptual database and the IPsec
    databases needs to be described by the protocol specification.
    Typically such a protocol would insert entries into the Security
    Association Database (SAD) when rows are inserted into the key table
    and remove SAD entries when key table rows are removed.  The
    protocol specification needs to describe how the SAD entries are
    constructed along with any other IPsec database entries that are
    needed, including a description of how these entries are ordered
    along with other IPsec database entries.  The question of whether it
    is desirable to use this conceptual database to manage protocols
    that use IPsec security services is open and has not been evaluated.

    Black,> [C] (Section 3) Where does key selection occur?  I would
    Black,> suggest that the database return all possible keys and let
    Black,> the protocol figure out what to use.  This is particularly
    Black,> important for inbound traffic for obvious reasons.

I think we've discussed key selection in the WG and come to a different
conclusion.  The key table selects the key.  We expect peer, key ID,
protocol and interface to identify a unique key for an inbound packet.

So, I think the concern you raise is not a problem.
While there was not a specific thread discussing key selection or this
issue, there were multiple reviewers who provided comments on key
selection over the development of the document, and making a major
change at this point without a technical problem seems undesirable.
If I'm missing something and the inbound packet issue is a problem then
we need to discuss it.