[6tisch] on the fallacy of default keys (was: Re: 6tisch join requirements for 6top)

Rene Struik <rstruik.ext@gmail.com> Mon, 24 November 2014 16:59 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FCF1A8724 for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 08:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=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 6F4ZwRI_zu93 for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 08:58:58 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13AE1A8721 for <6tisch@ietf.org>; Mon, 24 Nov 2014 08:58:57 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id y20so9194827ier.18 for <6tisch@ietf.org>; Mon, 24 Nov 2014 08:58:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XhdaPBv54ptjGuskjV4AGQB+No3ofdPW3iH1qgR9e7k=; b=qSGfFrq9TwTc3BJjHmAv1y13923fX1RSb+DZfkZafALfnyKR/xv98DUSwpMciqabcy 2Lk5EHyP0tnt7UXz2F6NrHvd6gfZy2NH/cDu5bTqInwyiUBaoRCZoqpm+YIOvrxxYqYP 9m54Q8HB03p0MOWFjpv50tW3742WwKetmiIKV6g3/5wG7WTNJXlfsbpG0GstiTtavOWp Y7viBX3YdOqYU+tCbqQzJhL1E3lr+GTKhQv5IwgEUziIpWLXz5AlztkJ/k9WkgFrXLeT 6Xd4Foyb6eQzhIhPVrMUZEWVMOt+FmEn11lEzNMtD0U9FnoxlRwIV2rNrAmZBNhH7XSq qIfg==
X-Received: by 10.50.47.14 with SMTP id z14mr12323216igm.38.1416848336786; Mon, 24 Nov 2014 08:58:56 -0800 (PST)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id fk8sm4747349igb.9.2014.11.24.08.58.55 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Nov 2014 08:58:56 -0800 (PST)
Message-ID: <547363C9.3090605@gmail.com>
Date: Mon, 24 Nov 2014 11:58:49 -0500
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Tero Kivinen <kivinen@iki.fi>, Michael Richardson <mcr+ietf@sandelman.ca>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com> <10653.1415740821@sandelman.ca> <CADJ9OA_LFkGDuyG_0bf=07d7cvC9FNRr5cMGTmYw2PR=g9XQHA@mail.gmail.com> <8193.1416253349@sandelman.ca> <21619.12717.53454.214321@fireball.kivinen.iki.fi> <E045AECD98228444A58C61C200AE1BD848A77CB5@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD848A77CB5@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/lCXwzJRSE_zcl5oHZiYMJo8R7fg
Cc: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>, Robert Moskowitz <rgm@htt-consult.com>
Subject: [6tisch] on the fallacy of default keys (was: Re: 6tisch join requirements for 6top)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 16:59:00 -0000

Hi Pascal:

Once again, the use of "well-known" keys is a bad idea, as a simple read 
of 802.15.4-2011 and 802.15.4e-2012 will confirm.

See also my message to the 6TiSCH list during the IETF-91 meeting below.

Best regards, Rene

[excerpt from my email of Wed November 12, 2014, 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02694.html]

Correction: I don't think I ever suggested the use of well-known keys(as 
you seemed to suggest below): (ab)using crypto with a well-knownkeys is 
a way (promoted by some, not by me) to make the mechanics of aprotocol 
work (in terms of I/O parameters), but does not accomplish anyof the 
semantics (in terms of delivered security properties:confidentiality, 
authenticity, and so on). In fact, it may cause lots ofsecurity 
problems, e.g., in the context of 802.15.4e, since it wouldallow 
poisoning frame counters (the ASN entry in the MAC PIB table).

Rene

On 11/24/2014 11:43 AM, Pascal Thubert (pthubert) wrote:
> Hello Tero,
>
>>> 10) the well-known beacon key to use for the join network. (Defaulting to
>>>     "6TISCHJOIN")
>> Why is this? What key Source it would use? What Key Id Mode? In 15.9 we
>> specify that the key management packets are sent with security level of 0, and I
>> did hear someone complaining that you cannot mix security level 0 and other
>> security level frames in the 15.4, but that is wrong. The 15.4 do allow receiving
>> packets with any security level, and upper layer is told about the security level of
>> the received frame in the DATA.indication call.
>>
>> Using well-known keys makes it bit harder for the upper layer to know whether
>> the frame actually has some protection or not. I.e. instead of checking whether
>> the security level is 0, it needs to check the KeyIdMode, KeySource and KeyIndex
>> to know if this key was one of the well know keys, which would indicate there is
>> no protection for the frames.
>>
>> If there is no protection for the frames, it is better to indicate it using security
>> level 0, and not hide that fact to some well know key.
>> Also if you define such key you also need to defined the KeyIdMode, KeyIndex
>> and KeySource for it.
> [PT] The use of a well-known beacon key (Defaulting to"6TISCHJOIN") has been debated for a while. The lack of an ethertype has already lead in the field to frame from protocol A being understood -wrong- by protocol B.
> Even if that looks anecdotic, we are now facing the need to reuse some messaging footprint in 6LoWPAN, and if that happens, we need to make sure that the overlapping protocol elements never mix in a same network.
> So, agreeably, the beacon key does not provide protection against rogues, but it does provide protection against unexpected impact of coexisting but incompatible protocols.
> IOW, the beacon key can be seen as an SSID that will isolate networks that are incompatible or should not be mixing for some policy reasons.
>
> The KIM would probably be 0 (correct?) and some meta would indicate the bundle that is used to join (a bundle reserved for that purpose actually), and on that bundle, no actual security can be expected, so all sort of preventive actions, such as defense against DoS, will be activated.
>   
>
> Cheers,
>
> Pascal
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363