Subject: [homenet] HNCP Security & Trust Draft

From: Steven Barth <[email-masked]>
Date: Fri, 03 Oct 2014 20:38:39 +0200

Hi everyone,

I took the last few days to gather some thoughts about threats, security 
and trust management
in the context of HNCP and wrote it up under 
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00

Quick overview over the topics:
* Homenet Border
* HNCP Payload Security
* Trust Management
* IGP-Considerations

Please note that this draft is in a very early stage so please help to 
make additions, provide feedback
and point out mistakes.

Regards,

Steven

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 6 Oct 2014 12:31:14 +0200 (CEST)

On Fri, 3 Oct 2014, Steven Barth wrote:

> make additions, provide feedback and point out mistakes.

Being a crypto novice, let me write some text and please tell me if it 
makes sense in the context of your draft (thanks for writing it, it looks 
like a good summary).

I like SSH. SSH generates its own public/private key, there are 
fingerprints I can put in SSHFP DNSSEC secured posts, etc. Are the 
public/private keys considered to be similar to self-signed 
"certificates"?

Anyhow, let me propose a scenario:

I get my first homenet router and power it up. It comes with a QR code on 
it, and it has a button (or NFC, similar principle). I scan the QR code on 
my smartphone (with a special homenet-control-app) which gives it enough 
information to connect to the wifi of the router, then I am asked to press 
a button on the router to allow my phone to become the administration 
device. The QR code contains wifi information and key fingerprint ID so my 
phone can decide that it's speaking to the correct device.

Now, after this, my phone app can speak to the router, and when I hook up 
another device to that router, it detects the new device, fingerprint ID 
etc, and asks me before it's allowed. After I ACK that it's allowed to 
talk to my homenet (which previously only consisted of a single router), 
they exchange session keys (or something) for management, so they can 
continue to talk. Just like with SSH allowing key based login, the 
management of homenet devices would rely on the public key for each 
accepted device being known to all the other devices, and this is how 
things authenticate. This would be the "anchor" that everything else 
relies on when it comes to security.

Now, the problem is what to do when I lose my phone and don't have any 
backup, so perhaps I need a user/password based login to add new 
administration devices, it seems hard to work around.

If someone gets the private key of any of the accepted homenet devices, of 
course everything falls down, but I don't see any way around it apart from 
having TPM etc.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Oct 2014 13:04:49 +0200

Hi Mikael,

thanks for your feedback.

> makes sense in the context of your draft (thanks for writing it, it 
> looks like a good summary).
I do not consider myself to be a crypto expert either which is one of 
the reasons I'd try to offload the actual crypto to something 
well-known. Also this probably means that what I drafted might not be  
100% accurate but I hope some of the actual expert will review it.

> public/private keys considered to be similar to self-signed 
I'll answer this in the context of the consensus based trust-scheme I 
added in addition to the PSK and PKI-based trust scheme. Yes, using 
self-signed certs here is possible since it's simply X.509.

> I get my first homenet router and power it up. It comes with a QR code 
> on it, and it has a button (or NFC, similar principle). I scan the QR 
> code on my smartphone (with a special homenet-control-app) which gives 
> it enough information to connect to the wifi of the router, then I am 
> asked to press a button on the router to allow my phone to become the 
> administration device. The QR code contains wifi information and key 
> fingerprint ID so my phone can decide that it's speaking to the 
> correct device.
Right that would be possible and the QR-code would be an additional 
"trust bootstrap ceremony" in that context. I actually had a phone / 
homenet-app scenario in mind when drafting this. So I was thinking about 
two possible cases.

Case #1: The app is bound to the router itself via some kind of 
vendor-specific RPC so it can control its configuration directly. That 
RPC allows the app to read / receive fingerprints and names when a new 
device attempts to join the homenet and allows the user to give a 
verdict (trusted / untrusted) which is then announced by the router 
itself and not the phone.

Case #1 is pretty obvious because it isn't really problematic and not 
bound to the phone itself and you could probably do the using some kind 
of webinterface on such a router.

Case #2: The app itself speaks HNCP, i.e. the base state synchronization 
part (not the routing, addressing, SD whatever). It is standalone (i.e. 
doesn't depend on a specific router, just has to peered with any HNCP 
router once so it is trusted) from then on it can itself announce trust 
verdicts about other routers.

>
> Now, after this, my phone app can speak to the router, and when I hook 
> up another device to that router, it detects the new device, 
> fingerprint ID etc, and asks me before it's allowed. After I ACK that 
> it's allowed to talk to my homenet (which previously only consisted of 
> a single router), they exchange session keys (or something) for 
> management, so they can continue to talk.
In Case #1 above it could tell the router to announce a trust verdict 
(trusted / untrusted) or in Case #2 it would do so by itself.

The session key exchange would then be done by the underlying protocol 
i.e. DTLS, IPsec/IKE, ...
The only real addition here should be that this underlying protocol (or 
its implementation) needs to allow a custom verification hook (i.e. 
notifies the HNCP daemon that there is a an unknown certificate and 
allows it to be accepted or not). For DTLS e.g. this shouldn't be 
problematic since most libraries seem to support such a callback.

> Just like with SSH allowing key based login, the management of homenet 
> devices would rely on the public key for each accepted device being 
> known to all the other devices, and this is how things authenticate. 
> This would be the "anchor" that everything else relies on when it 
> comes to security.
Yes, each device would announce the fingerprints of the certificates or 
public keys (details TBD) that it trusts in its HNCP-state.

> administration devices, it seems hard to work around.
Each device may announce verdicts about public keys / certificates and 
verdicts of device which are absent are cached by other HNCP routers so 
your case and Case #2 above would work without the app/phone always 
being there.

>
> If someone gets the private key of any of the accepted homenet 
> devices, of course everything falls down, but I don't see any way 
> around it apart from having TPM etc.
Yeah that's also the downside here. It's even more apparent if anyone 
can say someone else is trusted or not. But I guess ultimately its the 
same issue and once you are actually a trusted homenet router you can do 
more nasty things like messing with routing etc. than actually attacking 
the trust system itself, especially since most of the algorithms / 
applications run over HNCP are distributed / consensus based anyway.

Cheers,

Steven

---

From: Steven Barth <[email-masked]>
Date: Tue, 14 Oct 2014 09:37:28 +0200

I just pushed a new revision of the draft.
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01

Most notable changes:

* Some clarifications to the consensus based trust scheme
* PSK-management now supports key-derivation for different protocols
(IGPs, ...)
* Underlying crypto scheme changed to DTLS for now
* Some spellchecking, idnits etc.

Am Freitag, den 03.10.2014, 20:38 +0200 schrieb Steven Barth:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Oct 2014 08:34:52 -0700

1) i was hopeful that this might be a threats kind of draft which is 
sorely needed. i was disappointed.
2) there is a huge set of possibilities in between PSK and PKI in 
section 6.1 and 6.2. see #1.

Mike