Re: [homenet] HNCP security?

Douglas Otis <doug.mtview@gmail.com> Fri, 19 September 2014 17:15 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09AD1A0344 for <homenet@ietfa.amsl.com>; Fri, 19 Sep 2014 10:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t5g7FHwhnEp for <homenet@ietfa.amsl.com>; Fri, 19 Sep 2014 10:14:57 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A606A1A03A0 for <homenet@ietf.org>; Fri, 19 Sep 2014 10:14:49 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id i50so213847qgf.15 for <homenet@ietf.org>; Fri, 19 Sep 2014 10:14:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sduTq6vH2b8e0e5z8UXyeKrusWoznq3h6xd1CSAhrnQ=; b=tLU4TKVLDXxR3qmQI+innhotDC0IKy7685KFsK2tXIaToQfcryj7wued/gvooM+WHX 2Ls9rJBHIhkmprldZw+I7sMsOYtEI2NOSjRF8yojJqm4+cNkauE7tSysZWr560vUiwXm URxZijAdSkttgM1HjmDRgv/GIEE557iR13Gu4ATRlYHAEzX9jhAWM5OsJAFSp7gq9c04 i8NiDOz47hbfkMKGIusqt7q5KsU4gqOzzVT/z4ah0Zo5xxYF0hDAIhKacMVcIH66nAlm l1NyybJ2rRXQEOUyYwBFI09YnrCPsqzC9m1uPeMZ7oxs2ovQBe/nHKkxktuEcsIiom/4 RONg==
X-Received: by 10.140.108.200 with SMTP id j66mr3096684qgf.43.1411146888933; Fri, 19 Sep 2014 10:14:48 -0700 (PDT)
Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 95sm1836782qgm.18.2014.09.19.10.14.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 10:14:48 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <541C3AFC.3020507@openwrt.org>
Date: Fri, 19 Sep 2014 10:14:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BED7DD82-F681-4C09-8605-3CD4A8F8DE74@gmail.com>
References: <7BDD2D54-1058-4196-9BAD-770544096C93@iki.fi> <830.1410875532@sandelman.ca> <47647B8C-E3E6-4291-9F31-FBEE5FF53BFC@ecs.soton.ac.uk> <EMEW3|ba68076a23b44efccb32951649dba30aq8FLVJ03tjc|ecs.soton.ac.uk|47647B8C-E3E6-4291-9F31-FBEE5FF53BFC@ecs.soton.ac.uk> <alpine.DEB.2.02.1409170820460.14735@uplift.swm.pp.se> <5419A19F.1030808@mtcc.com> <alpine.DEB.2.02.1409180643250.14735@uplift.swm.pp.se> <541A7C1E.6090005@openwrt.org> <2D09D61DDFA73D4C884805CC7865E61130E839B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <FD0A639D-2B33-473C-9F91-5AD39B30BBF8@fugue.com> <0F4C6033-0D1F-4B5E-B47E-72F87F888C50@townsley.net> <E079CE93-BD9B-4D02-B327-DFA2EDE00602@iki.fi> <541C370D.2050704@mtcc.com> <541C3AFC.3020507@openwrt.org>
To: Steven Barth <cyrus@openwrt.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Wrl1r_jPMi_3NG25BRQxIFKIZms
Cc: homenet@ietf.org, Michael Thomas <mike@mtcc.com>, Douglas Otis <doug.mtview@gmail.com>
Subject: Re: [homenet] HNCP security?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Sep 2014 17:15:06 -0000

On Sep 19, 2014, at 7:17 AM, Steven Barth <cyrus@openwrt.org> wrote:

> Am 19.09.2014 um 16:00 schrieb Michael Thomas:
>> And it's extremely unlikely that
>> DTLS will be a one-sentence "solution" even if it gets adopted because DTLS, IPsec, etc say nothing
>> about enrollment and authorization. Those are by far the hard problems with homenent security.
> I wouldn't really want to lock HNCP to any trust scheme at this point where we are not even sure what we want. I'd rather choose the underlying mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe mention PSK-usage as baseline option and say various other certificate-based approached are possible but out-of-scope of the HNCP draft itself.
> 
> In practice users could probably run either their own in-home CA (e.g. like draft-behringer-homenet-trust-bootstrap) or we could add a web-of-trust-like extension to HNCP using transitive trust as proposed in draft-bonnetain-hncp-security or some weird combination. Either way it all stands and falls with the final user experience, e.g. the APP and the router's interaction with it for trust-bootstrap or the Web-UI/APP/Push-Button which let's you actively "trust" your peer in the web-of-trust approach. But user-experience isn't something we can really specify here.

Dear Steven,

As HNCP is deployed, there should be a sure way to ascertain a "home" network from that of outside traffic.  Wi-Fi Protected Setup (WPS) tried to allow home users an easy way to add new devices to an existing Wi-Fi network without entering long pass-phrases.  Making this easy for users, also made compromising the strategy easy for attackers.  Will NFC replace that of the vulnerable PIN?

Nor can ISP assigned prefixes be shared within a home environment without a sure way to exclude non-local traffic.  This should not depend on establishing cryptographic trust methods because this will not prevent users from being deceived; it simply changes what is being unreliably shared.  These methods must be bog standard to ensure plumbing works as expected.  One such method might attempt to establish an overlay network using the private address space defined for IPv6 and IPv4.

Regards,
Douglas Otis