Subject: Re: [homenet] HNCP

From: Ray Hunter <[email-masked]>
Date: Wed, 05 Mar 2014 09:35:58 +0100

> Steven Barth <mailto:[email-masked]>
> 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

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 5 Mar 2014 09:09:30 +0000

On 5.3.2014, at 8.35, Ray Hunter <[email-masked]> wrote:
> Is HNCP a useful place to standardise negotiation and maintenance of trust anchors?

I’m not sure. It is definitely feasible place for it, though..

> 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
> 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.

Given multiple scopes of HNCP (e.g. PA draft assumes that there is both linklocal and network-wide set of TLVs; currently only the later is done so we use network-wide TLVs even when we don’t need to in the implementation), this would be fairly straightforward to do; announce the faith negotiation mode using linklocal(ish) TLV, and then define an exchange that basically is just ‘hey, you want to trust me, right?’ and vice versa. 

We have a student look at this starting in April, but obviously input is solicited here too; is this a good idea? Should we instead assume public/private keys and associated trust data just show up magically and use that?

Cheers,

-Markus

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Mar 2014 11:19:08 +0100

Op 5 mrt. 2014, om 09:35 heeft Ray Hunter <[email-masked]> het volgende geschreven:

>> 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.
>> 
>> 
> 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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet