Re: [sidr] Key learning procedures in BGPsec?

[Richard Barnes <[e-mail]>]

"As simple as possible, and no simpler"

Your proposal is basically BGPSEC with MACs instead of digital signatures.  That doesn't work because another AS on the Internet can, e.g., poison a route by appending hashes computed with another AS's nonce.

The critical security feature of this system is that resource holders can only make statements about themselves.  In order for that to be the case, you really do need asymmetric cryptography: digital signatures vs. MACs/hashes.  Otherwise, in order for the world to be able to validate MACs, the MAC key needs to be published (the "nonce" in your example), which means that other entities can then generate valid MACs -- making statements about entities other than themselves.

--Richard



On Jan 31, 2012, at 12:57 AM, Brian Dickson wrote:

> On Mon, Jan 30, 2012 at 3:27 PM, Murphy, Sandra
> <[e-mail]> wrote:
>> Speaking as regular ol' member:
>> 
>> On Monday, January 30, 2012,  Brian Dickson said:
>> 
>>>> 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.
>> 
>> I reiterate my point: any  use of cryptography will require that you are careful with
>> the keying material.
>> 
>> Do you have any designs in mind that will NOT use cryptography?
> 
> There are two things to consider here.
> 
> (1) If I can come up with an example design that does not rely on
> private keys being kept (let alone exposed) on routers, would that be
> sufficient to justify exploring more options than just my example? I'm
> fine with someone else coming up with something better than this, and
> am not married to the particulars of this. However, it can be
> considered an "existence proof".
> 
> (2) Do you accept that an example of such a design is intended to
> prompt the merits of looking for better designs, rather than the
> example being fodder for dissection/discussion/bashing? I mean for
> this to be an "okay, fine, clearly there are alternatives, and we
> should discuss the high-level pros/cons of on-router crypto and key
> management".
> 
> 
> 
> Having said that, here's a simple example (with "simple" being in the
> eye of the beholder, obviously).
> 
> Each AS maintains a (for lack of a better term) "database" of its BGP
> neighbors, and known prefixes.
> 
> Each AS also maintains a single, global "nonce", which it may
> periodically change.
> 
> From these sets of data and the single nonce, each AS publishes a set
> of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix +
> neighbor_ASN + nonce) tuples.
> 
> How/where this gets published doesn't matter, but for example could be
> in a per-ASN DNSSEC zone.
> 
> Each router, upon receiving a BGPSEC update, adds to the BGPSEC
> hash-stack, the calculated SHA hash (of prefix + neighbor_ASN +
> nonce).
> 
> Each RP looks up each received _hash_ in the corresponding publication
> location, to determine the validity of that prefix's ASN_X-ASN_Y path
> element. The RP does _not_ calculate the hash - it is already there.
> 
> Publishing the hashes in DNSSEC zones scales reasonably well:
> 
> - The hash values only need to be generated or updated when policy
> changes (add/remove ASN neighbors) or the nonce gets changed. Thus,
> caching works well.
> - Large nonces ensure no collisions occur, and the zone is not
> enumerable/searchable. A 1024-bit nonce (just a random number, needn't
> be prime!) makes it completely impractical to try finding matches.
> - The relationships between ASNs, in addition to being evident in the
> AS_PATH (and/or AS4_PATH) are also represented _indirectly_ via the
> published information.
> - You have to already know the hash to confirm/deny the relationship,
> and then only for specific prefixes.
> - The relationships can be validated, but are not themselves exposed.
> Only the SHA hash is ever used for the validation itself.
> - Having a nonce is of little or no value, other than for being able
> to determine specific ASN neighbor relationships.
> 
> Validation is yes/no based on looking up the literal value from the
> BGPSEC field (which happens to be an SHA hash), but the RP does not
> actually calculate anything, only looks up the value.
> 
> The router sending the update (which includes the hash) doesn't care
> about who sent it the prefix - the hash remains the same _regardless_
> of from whom it was received.
> 
> The router sending the update is an RP, and only adds the hash if the
> validation succeeds (for every hash in the hash stack). Caching
> pre-validated hashes further optimizes update processing.
> 
> The bottom line on this scheme is, bad actor B can only attempt to
> spoof routes, where there are entries chained towards B of actual
> neighbor relationships, and where the originator of the prefix matches
> the RPKI. In other words, the worst that can be done is to leak "real"
> routes. There are other suggestions for addressing route leaks, which
> when combined with this, locks BGP down quite nicely.
> 
> NB:
> - This requires no deployed-on-router crypto of any sort.
> - There is a need for DNSSEC (and large zones at that), but that is
> centralized and cached.
> - Memory on commodity servers is cheap enough to not care, and the
> stateful nature of this scales even better
> - Depending on response time requirements, SSDs may handle zone
> size/cache size issues.
> - Other than occasionally rolling DNSSEC keys and nonces, there is no
> need for "beaconing" in this model.
> - DNSSEC signature expiry can trigger cache refresh, without requiring
> re-signing or route invalidation.
> 
> Brian, speaking only for himself.
> 
>> --Sandy, speaking as regular ol' member
>> 
>> ________________________________________
>> From: Brian Dickson [[e-mail]]
>> Sent: Monday, January 30, 2012 2:57 PM
>> To: Murphy, Sandra
>> Cc: Stephen Kent; [e-mail] list
>> Subject: Re: [sidr] Key learning procedures in BGPsec?
>> 
>> 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
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr