Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21

Michael Richardson <> Tue, 25 June 2019 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B3F01205DE; Tue, 25 Jun 2019 08:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E8VFguW80XoS; Tue, 25 Jun 2019 08:31:27 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id D4BD61205FE; Tue, 25 Jun 2019 08:31:13 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by (Postfix) with ESMTP id 75F3D3808A; Tue, 25 Jun 2019 11:29:29 -0400 (EDT)
Received: by (Postfix, from userid 179) id 81558109C; Tue, 25 Jun 2019 11:31:11 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 7E8D09BC; Tue, 25 Jun 2019 11:31:11 -0400 (EDT)
From: Michael Richardson <>
To: Tero Kivinen <>
cc: "Pascal Thubert (pthubert)" <>, David Mandelberg <>, "" <>, "" <>, "" <>, Thomas Watteyne <>, =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: MH-E 8.6; nmh 1.7+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: Tue, 25 Jun 2019 11:31:11 -0400
Message-ID: <26791.1561476671@localhost>
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jun 2019 15:31:30 -0000

Tero Kivinen <> wrote:
    > During the authentication the JRC needs to provide the keying material
    > to the joining node, but that does NOT provide protection against
    > spoofed ASN. After the node has actual keys used in the network it
    > still needs to verify the ASN by sending some message to JRC using
    > authentication and verify that JRC replies to that.

I thought that the 6LRs could provide authentication of the beacons with the
network-wide-key, and that we could (after the join process), verify the beacon we
saw, using the key(s) that the JRC provided.

    > If this 2nd step is omitted attacker do following attack:

>Joining node (JN)   attacker	     		  JRC
>		    <- beacon for ASN=23	  <- beacon for ASN=44
>See beacon
>from attacker,
>assume ASN=23.

So this is a replay of the valid beacon with ASN=23.

    > Now, if JN is using extended address to generate nonce, the nonce will
    > be different for all other nonces ever used, even the ASN is faked, and
    > has been used before. On the other hand if JN also receives short
    > address assignment from the JRC, JRC needs to make sure that short
    > address has not been assigned to anybody else before, as if it was used
    > by someone else, and frame sent by JN is encrypted, then attacker will
    > now have two packets with same ASN, and short address, meaning same
    > nonce, and it can now decrypt packets.

I thought that we have text in 6tisch-minimal about needing to rekey the
network if we run out of short-addresses for this reason.  Well, no.
We explain how to rekey well, but not why to rekey :-)

Are you suggesting that we need to put this in the architecture document too?
Maybe we should have included the ASN as an attribute in the JRC response.

    > If JN sends message to JRC which only JRC can reply, and uses wrong
    > ASN, the JRC will not be able to decrypt/validate that frame because of
    > wrong ASN in nonce, and will drop it silently, so if JN uses wrong ASN
    > it might be getting ACKs, but it will not get any real reply frames
    > back from real participants in the network. After it will not receive
    > confirmation from JRC that it has proper keys and ASN, it knows
    > something went wrong.

Still, that's more code to implement a heuristic.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-