Re: [sidr] Key learning procedures in BGPsec?

Stephen Kent <kent@bbn.com> Wed, 18 January 2012 19:39 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 D269621F85F1 for <sidr@ietfa.amsl.com>; Wed, 18 Jan 2012 11:39:15 -0800 (PST)
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 YFdcs3wOga7K for <sidr@ietfa.amsl.com>; Wed, 18 Jan 2012 11:39:15 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5084421F85EA for <sidr@ietf.org>; Wed, 18 Jan 2012 11:39:15 -0800 (PST)
Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49309) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RnbLd-000E4Y-B0; Wed, 18 Jan 2012 14:39:05 -0500
Mime-Version: 1.0
Message-Id: <p06240804cb3caa4fd051@[128.89.89.66]>
In-Reply-To: <A0B7EE2D-8E59-4DC8-9DC0-140E9574B479@verisign.com>
References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <A0B7EE2D-8E59-4DC8-9DC0-140E9574B479@verisign.com>
Date: Wed, 18 Jan 2012 14:26:23 -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: Wed, 18 Jan 2012 19:39:15 -0000

At 10:12 AM -0500 1/18/12, Eric Osterweil wrote:
>Hey Sandy,
>
>On Jan 17, 2012, at 8:20 PM, Murphy, Sandra wrote:
>
>>  About #1:
>>
>>  ROAs are used for origin validation.  (*) The bgpsec router needs 
>>only the prefix-AS binding in the ROA, not the crypto part, and 
>>only for the origin validation, not the signature attribute 
>>validation.  The rpki-rtr protocol is one way to communicate that 
>>binding. 
>
>I think I recall from another recent thread that there was some 
>contention over whether a router should just take it on faith that 
>the bindings are legit or if it needs to verify them.  Since I don't 
>recall that thread coming to consensus, rather than recreate that 
>here, I'm happy to leave this to the other thread if people think 
>that makes sense.

I don't recall that as a point of contention. The model for use of RTR is that
the set of routers that subscribe to a server in this protocol all trust the
server. If the server is managed by the operator of the AS in which 
the routers'operate, this is equivalent to the routers trusting the 
network management node for the AS.

>  > The bgpsec signature attribute validation does need the public 
>keys that are used to validate the signatures.  (And the binding to 
>an AS - see previous message.)  But it is the nature of the public 
>part of a public/private key pair that security concerns are lower 
>for communicating that part of the pair and exposure is no concern.
>
>I think we may not be speaking to the same point.  If a router gets 
>a private key installed on it (presumably one that has been vetted 
>to sign for an AS/prefix binding), then how do we get that key 
>installed securely?  If the router gets born with a key, how does an 
>AS manage the lifetime of that key?  That is, how do you envision it 
>gets rolled over to a new key, and how does that key get vetted and 
>installed? Again, I may just be missing the relevant part of some 
>draft, but I was not able to find this procedure concisely 
>documented.

PKIX has defined (CMC and CMP) protocols for cert requests that can 
be used if the router generates its own key pair. We are in the 
process of defining a new one that is simpler that than the two cited 
above. So there are multiple options here. If one chooses to generate 
a key and insert it into a router, then different protocols would be 
employed. (CMC is being enhanced to support this mode of operation, 
see draft-ietf-pkix-cmc-serverkeygeneration.

Steve