Hey Sriram, On Jan 18, 2012, at 8:42 AM, Sriram, Kotikalapudi wrote:
>> For that matter, what do people think about the issue that a private key >> could simply be covertly extracted from an AS' routers that are deployed >> in far off lands? Wouldn't this kind of compromise be a terrifying security >> threat to most ISPs? > > Eric, > > We (BGPSEC document authors) had considered this problem. > It is mitigated by having 'Key per Router' as discussed in: > http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01#section-4.5 > > 4.5. Key Per Router (Rouge Router Problem) > > 4.5.1. Decision > > Within each AS, each individual BGPSEC router can have a unique pair > of private and public keys. > > 4.5.2. Discussion > > If a router is compromised, its key pair can be revoked > independently, without disrupting the other routers in the AS. Each > per-router key-pair will be represented in an end-entity certificate > issued under the CA cert of the AS. The Subject Key Identifier (SKI) > in the signature points to the router certificate (and thus the > unique public key) of the router that affixed its signature, so that > a validating router can reliably identify the public key to use for > signature verification. Indeed, I knew about this (and even remember a NANOG discussion about it in Denver, I think). I mentioned one of my concerns surrounding this in an email, just moments ago: 1 - I think this could lead to quite a lot of state that consuming routers need, in order to verify any possible updates received from an AS. In the previous email, I gave a more detailed response. - but also - 2 - If there is such a compromise, how is it addressed? In order to get a new key in there, does someone need to send a whole new router to replace the old one? Do we envision putting sensitive private key info on some kind of electronic media and sending it via FedEx, etc? 3 - If new key material is to be shipped in to the same location that the last one was compromised in (in a new router, on a CD, or whatever) aren't we just putting the new key signing materials in the same not-so-secure-environment, and should we give some thought to how easy it might be to extract this information from a router? > > Sriram > > P.S. In case you had not seen the cited document > (draft-sriram-bgpsec-design-choices) before, > it is a design rationale discussion document and is a companion to > draft-lepinski-bgpsec-protocol-00.txt (our initial individual draft > submission). Yeah, I did see this. I guess I was hoping that there was some kind of discussion text, intuition, or an explanation of the intricacies that are inherent to this proposition (re: the comments I made above and in the last few emails). THanks for the pointer though. I'll re-read this draft's diffs (as I see it's been updated since Taipei), thanks! :) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
