Re: [6tisch-security] some proposed changes to 6tisch-minimal-security

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 10 March 2017 16:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A840129439 for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 08:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aSq1SNm1B2zW for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 08:39:43 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A84D128B38 for <6tisch-security@ietf.org>; Fri, 10 Mar 2017 08:39:43 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CC6EE20F; Fri, 10 Mar 2017 12:02:31 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C77BF6381A; Fri, 10 Mar 2017 11:39:41 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4 =87?= <malisa.vucinic@inria.fr>
In-Reply-To: <3057E0C5-157D-441B-8E76-6DB1E6D024B1@inria.fr>
References: <23046.1489099596@obiwan.sandelman.ca> <3057E0C5-157D-441B-8E76-6DB1E6D024B1@inria.fr>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Fri, 10 Mar 2017 11:39:41 -0500
Message-ID: <29942.1489163981@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/Shm6XfoWZnp5j6nR1Oou-PBn6Ks>
Cc: 6tisch-security@ietf.org
Subject: Re: [6tisch-security] some proposed changes to 6tisch-minimal-security
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2017 16:39:45 -0000

Mališa Vučinić <malisa.vucinic@inria.fr> wrote:
    >> +A pledge which receives only Enhanced Beacons containing Network ID
    >> extensions +{{I-D.richardson-6tisch-join-enhanced-beacon}} with the
    >> initiate bit cleared, SHOULD NOT +proceed with this protocol on that
    >> network.  The pledge SHOULD consider that it +is in a network which
    >> manages join traffic, it SHOULD switch to
    >> {{I-D.ietf-6tisch-dtsecurity-secure-join}}.

    > Sounds good. What happens in the case when the EB does not contain
    > Network ID extensions. Should we just default to minimal?

If it doesn't have that ID, then there probably isn't a Join Proxy available
on that network.  As minimal-security does not have another way to find the
Join Proxy, a pledge should ignore that EB.

    >> +{{I-D.ietf-6tisch-dtsecurity-secure-join}}.  + +If using a locally
    >> relevant certificate, the pledge will be able to validate the
    >> +certificate of the JRC via a local trust anchor.  In that case, the
    >> JRC will +return networks keys as in the PSK case.  This would
    >> typically be the case for +a device which has slept so long that it no
    >> longer has valid network keys and must go through +a partial join
    >> process again.

    > I am confused here. A node that sleeps so long that it no longer has
    > valid network keys can just repeat the Simple Join Protocol, i.e. the
    > join request/response exchange. It does not need to perform a new EDHOC
    > handshake because we can assume that the session key with JRC is still
    > valid, no?

It could try such a thing, yes, I agree.

It might also have moved enough that it can no longer speak to the same JRC.
The JRC might have restarted, etc.  The point is that if you have locally
verifiable certificates, then you can use them.  I don't know how OSCOAP
is going to securely signal when the secrets are no longer available.

    >> This makes it clearer that the mechanism is not limited to AES-CCM,
    >> but that negotiation could occur via EDHOC:
    >>
    >> https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/627b2bff648ccb9ec47c59d0cd8d710d9b64742b
    >>
    >> +The join request is typically authenticated/encrypted end-to-end
    >> using AES-CCM-16-64-128 +algorithm from {{I-D.ietf-cose-msg}} and a
    >> key derived from the shared secret from step 3.  +This is described in
    >> detail in {{I-D.selander-ace-cose-ecdhe}}, which also provides for
    >> algorithm agility.


    > Good catch for crypto agility. Will you make a pull request with these
    > changes so that I can integrate them before publishing -02?

done.

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