On 28.6.2014, at 10.43, Ray Hunter <[email protected]> wrote: >> How could [4] be prevented then? In ascending order of complexity.. >> >> [S4-1] Manual configuration of categories overriding automated border >> discovery. Defining either in the actual router product, or via >> configuration which interfaces to talk HNCP (and RP) on, where potential >> upstream links may never be, can be or always are. >> >> [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keying >> as currently specified in the draft. Setting up the shared PSK for the set >> of routers is left to the as manual configuration exercise for the owner of >> the devices. >> >> [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as >> [S4-2], may be able to get rid of manually keyed IPsec dependency. >> >> [S4-4] Some public key cryptography solution operating with just raw keys >> (there is a draft in the works on how to do this in HNCP) >> >> [S4-5] Some public key cryptography solution with CA hierarchy (similar to >> behringer-bootstrap) >> >> The big question is, are the S4-3+ really worth it? And what is the sane way >> to do it if they are? Can we actually become RFC with just S4-1 and S4-2? In >> case we go for public key-cryptography: what do we do about routing >> protocols mostly relying on shared secrets for authentication? >> >> - Markus and Steven > Powerline Ethernet devices have built in encryption, so I think consumers do > expect some level of protection from accidental neighbouring. I agree with > you questioning whether this should be solved at L2 or L3 and above.
Same thing with WPA* too of course. So I’m very tempted to assume L2 takes care of security.. ;) > Assuming the solution has to be defined at L3 and above, I think due to the > lack of any hierarchy, or root node, that you're going to have to have > individual keys/signatures per device, and that you cannot assume existence > of a central keying repository. > > S4-1 could work but relies on consumers plugging in devices into the correct > ports. S4-2 does not meet the requirement for auto-configuration. S4-3 could > work if you could bootstrap it, but that is not trivial either because it is > chicken/egg. I don’t see S5-5 flying: there is no natural root node or root > CA. S4-2 and S4-3 have same characteristics in my view - they need some (consensus) way to generate PSK, that is then either a) fed to IPsec as manually keyed SA, or b) used to encrypt-authenticate content in the protocol. S4-[45] have built-in ways of bootstrapping that are absent from S4-2/S4-3 as I see them. > The problem seems to boil down to "how can we bootstrap the trust" regardless > of the encryption technology. Assuming S4-3 or S4-4, when a new device is > added to the network (as opposed to existing devices being replugged) you > could check it against a (distributed) DB of existing pairing keys (via TBD > service discovery technology). If a device hasn't paired to at least one > other homenet device, HNCP messages from this device is ignored until it has. > Initiating the pairing should be as simple for the end user as pressing a > button on 2 connected devices (nearly) simultaneously (one new and one > already in the web of trust) so that both devices go into pairing mode and > learn a new HNCP pairing. Once homenet is (relatively) stable, you would also > be able to flood the new pairing to all other devices in the web of trust for > potential long term storage. At some point you might end up seeing old > devices you've given to your neighbour, so there should also be a way of > clearing the pairing DB for a specific device, or automatically flushing > entries for devices that have not been seen since time X. Alternative is that > you have to put all devices in homenet into pairing mode simultaneously, but > that may become less practical as the number of routers increases. > IF you can establish trust using HNCP (an expensive operation), it could be > the basis for all other trust in the Homenet, so it is potentially a big win. > e.g. To negotiate any necessary shared key for routing or other common > Homenet wide parameters: think election of the root bridge in 802.1 and then > that root device chooses a common shared key. Obviously distribution of the > resulting shared keys from the root is going to have to be encrypted. Yeah, I agree that this scheme (on high level) is what seems sensible _given_ the assumption you want to do the trust handling within HNCP. > I can certainly see this solution sketch requiring a lot of code. Indeed, and be also nontrivial to specify and interoperably implement. Sigh. So back to the original question, anyone have any idea if this stuff _must_ be implemented, really, beyond hand-wavy S4-1 and S4-2? Looking at Babel, the routing protocol spec is 45 pages, and draft specification of HMAC security scheme for it is 55 pages. I sense some slight imbalance somewhere. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
