Speaking as regular ol' member
On Tuesday, January 31, 2012, Ross.Anderson said: >If you want to authenticate a large number of messages from Alice to Bob that >all arrive in order then hash chains are great. That is not what we are looking for in the sidr work. Authenticating the stream of messages between two adjacent routers is not the sidr focus. Furthermore, there are solutions in hand (TCP AO, IPSEC, pt-pt physical protections, etc.). The sidr work is creating protections for the path - the AS_PATH attribute that is modified by each AS in the path of propagation of the BGP update. A sends an update to B, who adds itsself to the AS_PATH and sends to C, who adds itself and send the update to D, who.... The protections ensure that a recipient can look at an AS_PATH that shows A, B, C, D, ... and know that the update did in fact pass through those systems. And "in order" becomes a more complex idea as well. -Sandy, speaking as regular ol' member ________________________________ From: [email protected] [[email protected]] Sent: Tuesday, January 31, 2012 3:05 AM To: [email protected] list Cc: Murphy, Sandra; Brian Dickson Subject: Re: [sidr] Key learning procedures in BGPsec? Brian (delurk) As a recovering cryptographer I can think of nits to pick but it's certainly possible to build a robust system using hash chains and hash trees rather than conventional signatures. Declaration of interest: I started this field of study 15 years ago with a paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig and others and turned into systems (TESLA etc) for authenticating digital streams using hash chains. If you want to authenticate a large number of messages from Alice to Bob that all arrive in order then hash chains are great. Here's how it might work. You have a conventional mechanism for initial key setup between routers (maybe a route reflector doing public-key crypto, maybe DNSSEC). Then each router sets up a hash chain with each peer and uses hashes to authenticate routine updates. Steve Kent will point out that routers do in effect have key material, in the sense of not-yet-published hash preimages, and this is almost equivalent to using symmetric keys for MACs (not quite, as you can get some nonrepudiation from hash chains). But having local symmetric keys (or short-lived signature keys) managed by per-AS route reflectors, perhaps with HSMs for the bigger players, is in any case a good strategy to get resilience in the face of occasional compromise. So it might well be worth trying to explore the design options in more detail. The authentication mechanisms had better be cheap and resilient if we want this thing deployed Ross Anderson www.ross-anderson.com<http://www.ross-anderson.com> On 30 January 2012 23:57, Brian Dickson <[email protected]<mailto:[email protected]>> wrote: > 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.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
