Re: [karp] rt-dir review of draft-ietf-karp-crypto-table

Stephen Kent <kent@bbn.com> Tue, 28 May 2013 16:34 UTC

Return-Path: <kent@bbn.com>
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 B18C121F989B for <karp@ietfa.amsl.com>; Tue, 28 May 2013 09:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 BEpmjQIyRxzP for <karp@ietfa.amsl.com>; Tue, 28 May 2013 09:34:52 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C01E721F9889 for <karp@ietf.org>; Tue, 28 May 2013 09:34:52 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50004) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1UhMrJ-000LrU-Uv; Tue, 28 May 2013 12:34:50 -0400
Message-ID: <51A4DCA9.70109@bbn.com>
Date: Tue, 28 May 2013 12:34:49 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
References: <tslwqqswm6e.fsf@mit.edu> <519B99CA.9080307@bbn.com> <m2fvxffqp5.wl%randy@psg.com> <519CE6AE.3000102@bbn.com> <tsl38tdldjc.fsf@mit.edu>
In-Reply-To: <tsl38tdldjc.fsf@mit.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: karp@ietf.org
Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-table
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: Tue, 28 May 2013 16:34:58 -0000

On 5/23/13 3:08 PM, Sam Hartman wrote:
>>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
>      Stephen> Randy, You're right that each BGPSEC router has a private
>      Stephen> key. However, the key table is designed to manage key
>      Stephen> rollover for keys that are shared on a pairwise basis.  The
>      Stephen> private router key does not have that property, so it seems
>      Stephen> a bad fit.  I should have been more precise in my reply.
>
> Here are some of the reasons I think the key table is a bad fit for
> managing asymmetric key pairs:
>
> * Symmetric key pairs have both a public and private portion.
asymmetric
>    The
>    current key table is designed assuming a single asymmetric key.
symmetric
>    It
>    doesn't have a concept of a portion of a key row that can be public
>    nor does it have a concept of making sure the public key corresponding
>    to a private key row is available.
I agree that the key table is not a good fit for these reasons.
> * You often need additional public information such as certificates (or
>    in some cases CRLs or cached OCSP responses) to provide to a relying
>    party to make an asymmetric key useful.  The key table is not designed
>    to manage this information.  I don't know much about BGPSEC, but my
>    assumption is that it builds on the RPKI's certificate and key
>    management practices.  If so, those practices seem very specialized to
>    build into something like the key table.
more good reasons. Yes, BGPSEC makes use of the RPKI for distribution
of certs and CRLs for router keys.
> * The concepts of peers, interfaces, key names and protocol specific
>    information seem inappropriate to private keys.
secret

Yes, BGPSEC router keys are neither peer nor interface-specific.

Steve