Re: [sidr] Key learning procedures in BGPsec?

Stephen Kent <kent@bbn.com> Thu, 19 January 2012 22:18 UTC

Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1AB21F8604 for <sidr@ietfa.amsl.com>; Thu, 19 Jan 2012 14:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Level:
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DgCoK1v2Eb75 for <sidr@ietfa.amsl.com>; Thu, 19 Jan 2012 14:18:37 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5721F85D5 for <sidr@ietf.org>; Thu, 19 Jan 2012 14:18:37 -0800 (PST)
Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49333) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Ro0JW-000ACr-NE; Thu, 19 Jan 2012 17:18:34 -0500
Mime-Version: 1.0
Message-Id: <p06240807cb3e3e117777@[128.89.89.66]>
In-Reply-To: <CCE15AEB-D606-4A59-8118-BA5CD53413E8@verisign.com>
References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <A0B7EE2D-8E59-4DC8-9DC0-140E9574B479@verisign.com> <p06240804cb3caa4fd051@[128.89.89.66]> <CCE15AEB-D606-4A59-8118-BA5CD53413E8@verisign.com>
Date: Thu, 19 Jan 2012 16:45:08 -0500
To: Eric Osterweil <eosterweil@verisign.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] Key learning procedures in BGPsec?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2012 22:18:37 -0000

At 3:07 PM -0500 1/19/12, Eric Osterweil wrote:
>...
>
>Like I said, this is not something I (personally) feel the need to 
>rehash here.  If those on the other thread ("[sidr] I-D Action: 
>draft-ietf-sidr-rpki-rtr-23.txt") were content w/ its resolution, so 
>be it.  But, iirc, there seemed to be some... lingering 
>disagreement, no?

I think there was confusion re this topic, and that the RYR protocol 
doc could be improved by adding text in the security considerations 
section to clarify the trust model envisioned by the authors.

>...
>
>I just took a read through that draft, thanks for the pointer! :)

you're welcome.

>OOC, were you all imagining that the CMC authentication for these 
>BGPsec routers would use a shared secret or a pre-installed 
>certified key o each remote router?  Also, do you happen to know 
>which nation states require key escrow these days?

This is a local matter, so each ISP can decide what approach they 
wish to adopt. I personally prefer installing the cert for the CA.

When key escrow has been required, it has usually been mandated for 
keys used for encryption, not for integrity or authentication. Since 
we're discussing integrity & authentication here, it is not clear 
that there are any applicable key escrow regulations.  Also, the IETF 
general policy has been to ignore any nation-specific crypto 
regulations when  developing standards.

Steve