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