Re: [sidr] Key learning procedures in BGPsec?

[Stephen Kent <[e-mail]>]

At 10:38 PM -0500 1/19/12, Eric Osterweil wrote:
>
>  > 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?

The focus of BGPSEC is improving inter-AS routing security. The 
operator of any AS may not do a great job of securing the keys 
associated with some or all of its routers. Other ASes will not, in 
general, be able to evaluate the operational security of an AS. 
BGPSEC tries to limit the extent to which an AS  can lie about routes 
that it propagates. Local (within an AS) security errors or poor 
practices do not undermine this security feature.

>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)?

A CA issuing certs to routers in an AS must have a way to verify that 
a cert request is form a legitimate source. There are various ways 
this can be done and, ultimately, this too is a local matter.

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

Typically no, because the use of the key being issued is for signing.

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

In general it is appropriate to worry about operational issues. But, 
I'd suggest that key escrow is not within scope, based on previous 
IETF experience in related areas.

Steve