Re: [homenet] HNCP

Op 5 mrt. 2014, om 09:35 heeft Ray Hunter <v6ops@globis.net> het volgende geschreven:

>> Steven Barth <mailto:cyrus@openwrt.org>
>> 14 February 2014 20:29
>> 
>> I think your arguments about the downsides are valid and we have thought about them as well. However the current approach seems to be practical given the current situation that there is no common consensus about an IGP or about there even being an IGP that fits all use cases. Some people even argue that in some or many common cases an IGP might be overkill.
>> 
>> On top of that I even think if there would be a consensus in the near future then we still need autoconfiguration and source+dest routing standardized and adopted for that given IGP which will probably take quite some time as well.
>> 
>> So yes, there are limitations and hopefully this is not the final stance on this topic and at some point there is some kind of industry-consensus on an IGP. But honestly I don't see this happening any time soon.
>> 
>> 
>> ------------------------------------------------------------------------
> Thinking further about what should or should not be in HNCP.
> 
> Is HNCP a useful place to standardise negotiation and maintenance of trust anchors?
> 
> I know many pieces of kit support a 'peer now' button (Bluetooth audio, DECT phones, Powerline Ethernet), which triggers a leap of faith that direct neighbours in the same mode are trustworthy, but I'm not aware of any IETF standardised way that Homenet devices could negotiate e.g. a common encryption key or private root certificate.
> 
> As a rough sketch:
> 
> an external trigger [physical button, GUI command, first power on, factory specific action] places one or more devices into "leap of faith" mode
> each device generates a candidate encryption key or private key on the fly
> device detects direct neighbours in similar leap of faith negotiation mode
> two neighbouring devices establish a secure channel between the pair
> neighbouring devices exchange certificates or keys and optionally enter them into a store, so that the direct neighbors can authenticate each other in the future without entering leap of faith mode.
> 
> Devices periodically flood a public key throughout the homenet, with the flooding being authenticated across each pair of neighbours using the trust established above, or a HNCP key or certificate that has been previously established.
> During the flooding, if A trusts B and B trusts C then A trusts C.
> All devices end up with a copy of every other device's public key. Each device has its own private key.
> 
> For maintenance, a timer triggers key or certificate roll over of existing established neighbour trust relationships
> 
> This HNCP established key or certificate can be used to authenticate future HNCP messages (e.g. between two devices that were not direct neighbours, but become neighbours, because one device has been replugged), or other messages in other protocols.

On user friendly trust maintenance, I would use by mobile to let my new devices join my homenet. Also, I would use the app for excluding devices I don’t own anymore. I’m not sure the mechanism needs to be build on a distributed database or has a more centralized approach. Perhaps use the zero dependency rule and avoid SPOF.

Having my portable gear be part of HNCP would introduce additional requirements on merge of the distributed database, on for example conflict resolving.

Teco

> 
> -- 
> Regards,
> RayH
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet