Re: [sidr] Key learning procedures in BGPsec?

[Eric Osterweil <[e-mail]>]

Hey Steve,

On Jan 18, 2012, at 2:26 PM, Stephen Kent wrote:

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

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?

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

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

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?

Thanks!

Eric