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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
