Re: [secdir] Comments on draft-richardson-6tisch--security-6top-04.txt

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 08 December 2014 19:34 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1761ACDF5; Mon, 8 Dec 2014 11:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] 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 wBg8pkeudEbY; Mon, 8 Dec 2014 11:33:52 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670901ACDF1; Mon, 8 Dec 2014 11:33:29 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BA602200A7; Mon, 8 Dec 2014 14:37:06 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 6973F637F5; Mon, 8 Dec 2014 14:33:28 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4F0CB63745; Mon, 8 Dec 2014 14:33:28 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Hilarie Orman <hilarie@purplestreak.com>
In-Reply-To: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com>
References: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 08 Dec 2014 14:33:28 -0500
Message-ID: <27587.1418067208@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3zcACNWnMvtWCBZx2bpk9lm2-KA
Cc: 6tisch-security@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Comments on draft-richardson-6tisch--security-6top-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Dec 2014 19:34:00 -0000

re: https://mailarchive.ietf.org/arch/msg/secdir/qxT9Cx6mue0UhlPd4dUJU3A8IX8

Hilarie Orman <hilarie@purplestreak.com> wrote:
    > A minor issue with the protocol is the encryption with a well-known
    > key.  This serves no security purpose, but it allows traffic filtering
    > to keep the traffic on the special Join Network separate from the
    > regular network.  That confuses me --- surely some packet marker would
    > be better for filtering than encryption would?

sadly, 802.15.4 lacks both the SNAP header, and even such a thing as an
ethertype.  But, we have decided to dispense with this in a new revision.

    > Another confusing point is step 1B "send router solicitation".  I'm
    > not sure what destination address is in this.  Perhaps the beacon
    > provides the information for use by the joining node.

IPv6 router solicitations are multicast, so it does not need to know a place
to send it.

    > It seems clear that the initial communication must have mutual
    > authentication.  I'd expect the joining node to start with a signed
    > join request, and nothing would proceed further until the JCE found
    > the device ID in its access list and decided to proceed with
    > further authentication.  The joining node should not communicate
    > further until it has some reason to believe it is on the correct
    > network.

The intent is that the device ID travels up the network to the JCE, just as
you said, and that the device stays silent until the JCE see it.  You are
suggesting that the new device sign it's ID.  Can you explain the value of
that?
(The exact way in which the device ID travels up has changed several
times. We believed that we could use an extended ARO in the IPv6 Neighbour
discovery which is part of 6lowpan, but we are having some doubts)

    > Even with that change, there is always the possibility of a malicious
    > relay node-in-the-middle.  It could cause the joining node to
    > communicate with a very distant instance of the correct network, for
    > example.  This might violate some proximity assumptions.  The
    > malicious node could arbitrarily block communication and cause
    > unintended behavior of the network.

Yes, so in draft-ietf-roll-security-threats (in AUTH48) this is called a
wormhole attack.  It's unclear how this situation is different than
(intentionally) having a really good antenna, but I agree it is a concern.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-