Re: [sidr] Key learning procedures in BGPsec?

[Stephen Kent <[e-mail]>]

At 1:43 PM -0500 1/24/12, Eric Osterweil wrote:
>...
>  >
>>  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.
>
>This seems almost like a self-contradictory statement.

I guess I should be happy that you included "almost" :-).

>   How is the system improving AS security if keys can only be 
>deployed over a potentially compromised medium, and there is no 
>provision for CAs, signers, RPs, etc. to express partial trust?

Trust is subjective, not transitive, and a poor choice for a metric. 
Each AS operates in whatever way it chooses. This is already true 
with regard to local routing policy, quality of network management, 
subscriber service, etc. This same notion extends to the security of 
its BGPSEC operation.

Having an AS assert how well it secures it's BGPSEC router keys is a 
self-evaluative declaration. It is not very meaningful re the 
security guarantees that BGPSEC offers. Each AS operator is a CA, but 
it's not as though relying parties can choose a different CA to 
attest to the authorization of these routers to represent the AS. The 
operator is authoritative for this info.

One way to think of this is, if you are willing to do business with 
an AS operator, irrespective of its use of BGPSEC, you should be at 
least as happy when the operator deploys BGPSEC. Deploying BGPSEC 
will not make the operator "better" relative to other aspects of its 
operation; hopefully it also will not make the operator worse.

>   With BGPSEC, we are already assuming some degree of trust imparted 
>by signatures, but your comment above suggests that there should be 
>some further understanding that "other ASes" cannot evaluate the 
>trustworthiness of what they are consuming...  If this is the case, 
>I would worry that we are worse off with this false sense of 
>security...

I don't belive we are creating a false sense of security, but there 
may be confusion about the security model for BGPSEC.

A major goal of BGPSEC is to limit the extent to which 
errors/misbehavior by an AS operator, or a successful attack against 
an AS operator, can adversely affect other ASes (re routing). The 
RPKI limits the (verifiable) assertions that an AS operator can make 
about the AS that its routers represent, and the prefixes it can 
originate. The BGPSEC per-AS-hop sigs limit the assertions the AS can 
make re what routes have been advertised to it. These guarantees 
still apply whether the operator does a good or poor job of router 
key management.

>To put it differently, I think this highlights a misalignment 
>between the design of BGPSEC and what operators are going to have to 
>deal with.  We're not giving any choice to operators that will 
>essentially have to risk compromise, or not play in this system at 
>all...

I disagree with your characterization of the situation. One 
anticipates that an operator will prefer signed routes to unsigned 
routes, although that is still a local choice. You seem to be 
suggesting that if an operator were to publish the equivalent of a 
CPS re its router cert secruity management, then other operators 
could use this info to decide how much to trust signed updates. While 
I agree that one could imagine this sort of trust model, it becomes 
very complex very quickly. Experience suggests that users are not 
good at managing such complex trust models. Also, since the data is 
self-reported, it's not clear how one ought to weight it. So, we have 
adopted a much simpler trust model.

>...
>  > 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.
>
>Actually, I think this is a "turtles all the way down" issue.  I 
>cannot see any silver bullet here that solves this (which is what 
>I'm trying to highlight).  We can't bootstrap trust in a BGPSEC 
>router's key w/o some external handshake, but we can't bootstrap 
>that handshake without some external cert, but we can't bootstrap 
>that without... etc.  Deploying a remote signer with sensitive 
>information (private keys, shared secrets, etc.) seems to be a 
>serious problem...

I'm puzzled by your comments above. CAs have used various methods to 
provision certs to users and to devices for years. Each Cisco VoIP 
phone has a vendor-installed cert and private key, and this has been 
true for years. One might image a similar feature for BGPSEC-enabled 
routers. This cert could be used to bootstrap issuance of a BGPSEC 
cert. The EST draft explicitly incorporates this notion. This is an 
elegant approach to cert issuance, but it's not the only option. So, 
as in many other PKI-based systems, the specific means by which a CA 
provisions certs will remain a local matter.

If a router is in a location that the operator considers risky, it 
might choose to use a per-router cert for that device, while sharing 
a cert/key for other routers. That is a per-operator choice.

>...
>  >
>>  Typically no, because the use of the key being issued is for signing.
>
>But the diagrams show encryption.  Are the KGRes private keys to be 
>sent in the clear then?

The issue is not whether encryption is used at any point in a key 
provisioning process. The issue, typically, has been what is the 
purpose of the key that might be subject to an escrow policy. But, in 
any case, I think key escrow is a red herring.

>...
>  > 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.
>
>OK, I suppose my parting thought on this escrow issue, then, is that 
>having to negotiate key escrow is an issue that operators will be 
>required to face with this system, and I am worried that our working 
>group's secure design might be a non-starter for some unless we try 
>to address this issue it in the design.  I really feel like we need 
>to fix this to keep our design relevant.

I see nothing to fix.

Let's consider an AS operating in Elbonia. Let's assume that the 
Elbonian government imposes key escrow on router keys used with 
BGPSEC. This implies that signed updates from an AS operating in 
Elbonia  might really be bogus, generated by the Elbonia secret 
police (the notorious ESP). How is this different from the ESP taking 
over the AS, coercing the operators of the AS to emit bogus updates? 
Since BGPSEC is employed, the AS cannot emit verifiable routes that 
have not been sent to them. Thay cannot originate verifiable bogus 
routes for prefixes not allocated to them. The secruity guarantees 
provided by BGPSEC are designed to limit the damage that occurs if an 
AS makes errors, behaves badly, or is compromised.  Attacks based on 
key escrow are just one form of compromise.

Steve