Re: [sidr] Key learning procedures in BGPsec?

["Murphy, Sandra" <[e-mail]>]

Speaking as a regular ol' wg member:

Brian says:

>If poor key management on W makes it possible for the private keys of
>a single router in W's network to be learned by B, then all bets are
>off for anything advertised via W.

Actually, you can stop with "all bets are off".

Any use of cryptography relies on the protection of the keying material.  The
assurance is not that a particular person/entity can do something, but that the
holder of the keying material can do something.

So like sharing your password to your bank account means that someone else
can appear as you to the bank, sharing your keys lets someone/something else
act as if they were you.  That is why key compromise is a serious issue.

This is common to anything that uses cryptography.  It is not specific to this
particular application.  Exposing the keys in DNSSEC, exposing the keys in https,
exposing the ssh keys, exposing passwords, etc., will all affect the assurance 
provided by the cryptography.

I do not see any requirements here that would make that any different than any other
use of cryptography in any other environment, so I do not see any need for
the protocols here to provide solutions.  Pointers to operational guidance 
elsewhere, where it exists, perhaps.

--Sandy, speaking as regular ol' member


________________________________________
From: [e-mail] [[e-mail]] on behalf of Brian Dickson [[e-mail]]
Sent: Monday, January 30, 2012 1:07 PM
To: Stephen Kent
Cc: [e-mail] list
Subject: Re: [sidr] Key learning procedures in BGPsec?

On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent <[e-mail]> wrote:
> 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.
> 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.

This is a stated goal, but how this achieved or achievable relates
greatly to key management.
See below for why I think there are issues with the current protocol
design vs key management.

> These
> guarantees still apply whether the operator does a good or poor job of
> router key management.

I disagree with this assertion.

Let's consider off-axis risks.

Originator O, Relying party R, Weak-operator W, and Bad Actor B.

If poor key management on W makes it possible for the private keys of
a single router in W's network to be learned by B, then all bets are
off for anything advertised via W.

Here's why:

Presume all the good stuff you want about O, and the RPKI system.
Route X, originated by O, is fully validated and legitimate.

Topologically, let's say the following BGPSEC sessions and links exist:

O--?--W--?--R--?--B--?

(All the "?" mean there could be intermediate parties, but none are
required for this example to still be applicable.)

In order to spoof announcements, B need two things: The private key of
a single router (such as the key for a W router), and the data that
would be signed by that router (for X).

However, since anyone receiving route X which was sent from O via W
_must_ contain that data, it is trivial for B to generate false routes
for O.

The process would be:
B sets up a router F ( which claims to be the W router for which the
key was compromised).
The (W_fake) router F is configured with ASN == W.
B sets up a BGPSEC session between F and B, and signs the results.

Voila, BGPSEC signed routes received by R, that appear to be:

O--?--W--B--?--R

and this BGPSEC-signed path is fully origin-validatable and fully
BGPSEC path-validatable.

An error by W, allows B to "pwn" O, without O or R doing anything wrong at all.

There is no (trivial) way for R (or O) to detect or prevent this kind of attack.

This shows why one or more of the following things needs to be changed
in the BGPSEC design:
(1) key management requirements (not part of the design)
(2) availability of unencrypted signature-input data to off-axis parties
(3) ability for a single signature to subvert the validation process
(4) absolute trust model for signature chains (all/nothing)
(5) ???

Brian
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr