Re: [homenet] HNCP

[Ray Hunter <[e-mail]>]

> Steven Barth <mailto:[e-mail]>
> 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.

-- 
Regards,
RayH