Re: [sidr] Key learning procedures in BGPsec?

Eric Osterweil <eosterweil@verisign.com> Fri, 20 January 2012 03:39 UTC

Return-Path: <eosterweil@verisign.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 063FE21F8597 for <sidr@ietfa.amsl.com>; Thu, 19 Jan 2012 19:39:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vc3qvkqYbDV6 for <sidr@ietfa.amsl.com>; Thu, 19 Jan 2012 19:39:10 -0800 (PST)
Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6EC21F8594 for <sidr@ietf.org>; Thu, 19 Jan 2012 19:39:09 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKTxjhzn0NeKyK82HrxqxkHf1BksqEddmL@postini.com; Thu, 19 Jan 2012 19:39:10 PST
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0K3cquN019657; Thu, 19 Jan 2012 22:38:52 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.67]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 22:38:52 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <p06240807cb3e3e117777@[128.89.89.66]>
Date: Thu, 19 Jan 2012 22:38:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@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> <p06240807cb3e3e117777@[128.89.89.66]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 20 Jan 2012 03:38:52.0050 (UTC) FILETIME=[07248F20:01CCD725]
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: Fri, 20 Jan 2012 03:39:11 -0000

On Jan 19, 2012, at 4:45 PM, Stephen Kent wrote:

> At 3:07 PM -0500 1/19/12, Eric Osterweil wrote:
> 

<snip>

> 
>> 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.

Yeah, I see.  I agree that it should be a local policy decision, but then how does this avoid my initial concern about relying on crypto material that has been dispatched through customs (or some other suspect medium), where key material could be intercepted and extracted?  Also, is it safe to assume that you would need the CA(s) to restrict access to just your own routers (so that unknown routers/certs cannot issue KGReqs that result in KGReses)?

> 
> 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.  

Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't the curly braces denote encrypted material?  I thought the responses in the key exchanges where necessarily encrypted in this protocol?  Otherwise, the new private key is sent in the clear.  I fully accept the possibility that I'm confused here, but if the material is encrypted and needs to be decrypted, would the corresponding keys be subject to escrow policies?

I'm sure someone is about to remind me that this is not a PKIX list, but I just want to make sure that I understand how we are proposing to use this protocol. :)

> Also, the IETF general policy has been to ignore any nation-specific crypto regulations when  developing standards.

I see, I guess I had thought we should be worried about the eventual operational issues that might arise.  I didn't know this was taboo, but shouldn't we find a way to address these concerns in order to help ensure the design's operational relevance when it's finished?  I'm just bringing this up in the sprit of making this design more relevant, not because I think there should be some official linkage to escrow policies or anything.

Eric