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.
- [karp] Gen-ART review of draft-ietf-karp-crypto-k… Black, David
- Re: [karp] [Gen-art] Gen-ART review of draft-ietf… Jari Arkko
- Re: [karp] Gen-ART review of draft-ietf-karp-cryp… Sam Hartman
- Re: [karp] IANA policy for draft-ietf-karp-crypto… Sam Hartman
- Re: [karp] Gen-ART review of draft-ietf-karp-cryp… Stephen Kent
- Re: [karp] Gen-ART review of draft-ietf-karp-cryp… Uma Chunduri
- Re: [karp] IANA policy for draft-ietf-karp-crypto… Black, David
- Re: [karp] Gen-ART review of draft-ietf-karp-cryp… Black, David
- Re: [karp] IANA policy for draft-ietf-karp-crypto… Carter Bullard