From dcd61bd0f90b4b78d9b00d6991310b0f78d90351 Mon Sep 17 00:00:00 2001 From: kaiserd Date: Fri, 10 Jun 2016 18:59:25 +0200 Subject: [PATCH] added ideas to device pairing todo section --- draft-huitema-dnssd-privacy.xml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-huitema-dnssd-privacy.xml b/draft-huitema-dnssd-privacy.xml index 03f3534..ff67def 100644 --- a/draft-huitema-dnssd-privacy.xml +++ b/draft-huitema-dnssd-privacy.xml @@ -1026,9 +1026,13 @@ obfuscated host name. TODO: need to define the pairing service, or API. The API approach assumes that pairing is outside our scope, and is done using BT-LE, or any other existing mechanism. This is a bit of a cope-out. We could also define a pairing system that just sets the pairing with equivalent security as the "push button" or "PIN" solutions -used for BT or Wi-Fi. And we could at this stage leverage pre-existing security association, e.g. PGP +used for BT or Wi-Fi. And we could at this stage leverage a pre-existing security association, e.g. PGP identities or other certificates. If we do that, we should probably dedicate a top level section to specifying the minimal pairing service. + +Using a pre-existing asymmetric security association, we can use a key exchange similar to +IKEv2 (RFC 7296). IKEv2 leverages the SIGMA protocols, which provide various methods of authenticated DH. +It would also be possible to authenticate DH using symmetric passwords (e.g. Bellovin-Merritt).