Hi Mikael,
thanks for your feedback.
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 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.
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"?
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.
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.
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.
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.
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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
