On Mon, Jan 30, 2012 at 3:27 PM, Murphy, Sandra <[email protected]> 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 [[email protected]] > Sent: Monday, January 30, 2012 2:57 PM > To: Murphy, Sandra > Cc: Stephen Kent; [email protected] list > Subject: Re: [sidr] Key learning procedures in BGPsec? > > On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra > <[email protected]> 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: [email protected] [[email protected]] on behalf of Brian >> Dickson [[email protected]] >> Sent: Monday, January 30, 2012 1:07 PM >> To: Stephen Kent >> Cc: [email protected] list >> Subject: Re: [sidr] Key learning procedures in BGPsec? >> >> On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
