Re: [sidr] Key learning procedures in BGPsec?

[Brian Dickson <[e-mail]>]

On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra
<[e-mail]> wrote:
> 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.

Correct.

My point was, and is, that _this_ particular design, as has been
proposed to the WG,
is what is placing the requirement for private key material, and the
consequent need
to protect said material.

Without going into details of alternative designs, it is enough to
point out, IMHO, the distinctions:

signatures - requires signer to possess private key,
recipient(s)/validators need public key
encryption - requires sender to have the public key(s), and the
recipient(s) need their respective private keys.

There are other kinds of encryption as well, which involve shared
keys, or in case of DH, random session keys with neither party
having/needing the other's key material.

What I'm saying is, I don't believe enough attention has been paid to
the private key on the router requirement, or its implications.

The designers of the protocol really need to justify their choice. It
is not enough to wave hands at this and say, "operational docs will
cover this".

> 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 an apples vs oranges thing. There is an end-to-end encrypted
session (SSL), and there is no requirement for private key
distribution.

The bank has its SSL private key, which is neither distributed, nor
exposed operationally. Then there's all the L8/L9 stuff related to
record keeping etc. (SOX etc.)

The primary issue is the creation and exposure of private keys.
If the protocol requires FIPS-140 (to whatever level/degree) to ensure
it does not introduce weakness or risk, that is something that needs
to be addressed.
Or, it may be a non-starter if that is a requirement, but the WG needs
to make an informed decision.

This isn't the kind of stuff to be taken lightly - it strongly impacts
deployment and operation, and cost of deployment (and/or risks).

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

DNSSEC uses effectively out-of-band management for securely
distributing public keys (which is what DS uses).
DNSSEC supports centralized signature models with HSM  use being very scalable.

SSH also uses distribution of public keys and supports encrypted
storage of private keys (presumably in physically secure local
storage).

This would be the first major deployment of private keying material in
geographically diverse locations, that I'm aware of, for the protocol
to function as described.

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

I'd say it goes beyond operational guidance, and to the heart of the
protocol design.

It is not beyond fixing, but IMHO, desperately requires fixing. At
least if it stands a chance of being deployed in the real world.

Brian (speaking ONLY for myself).

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