Re: [homenet] HNCP

[Markus Stenberg <[e-mail]>]

On 5.3.2014, at 8.35, Ray Hunter <[e-mail]> wrote:
> 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’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
> 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.

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