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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 24 November 2014 17:09 UTC

Return-Path: <pthubert@cisco.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 EF2BC1A8758 for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 09:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Level:
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 2AXvW-mh_SuC for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 09:09:48 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76161A8754 for <6tisch@ietf.org>; Mon, 24 Nov 2014 09:09:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4976; q=dns/txt; s=iport; t=1416848988; x=1418058588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TkjjFt9b+RWLXU1NJYLCQf+OL4w84+HGEvuJBi1SuNM=; b=bClFnz6cjeNsZxCEbZp4OiUIp+Bz3fIDggHFr2q3EJI1D4viR/NRDhuu jHxbSvrIEnq3WF5qD70p1rGIvNc+YPug711e8jI/6GBAov0truTv+TWDV TFNeZihq8G9gDPaJOgPtEJpe0yxuGUudhObsuo2J5PwTMYPP8rEt2onFs g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj4FAPtlc1StJA2I/2dsb2JhbABYA4MOVVQFBMhigi8KhhVVAoEeFgEBAQEBfYQCAQEBBAEBAWsLDAQCAQgOAwQBAQEKHQchBgsUCQgCBAENBQgBiCMDEggFyUINhkYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXinGDXYFQCxACAR4hEAcGC4MegR8Fi2mDDINzigSDSYcRh1cDhnuCOIFFeIFIgQMBAQE
X-IronPort-AV: E=Sophos;i="5.07,450,1413244800"; d="scan'208";a="99628437"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 24 Nov 2014 17:09:47 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAOH9kOQ017645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 17:09:46 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 11:09:46 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rene Struik <rstruik.ext@gmail.com>, Tero Kivinen <kivinen@iki.fi>, Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: on the fallacy of default keys (was: Re: [6tisch] 6tisch join requirements for 6top)
Thread-Index: AQHQCAfw05RMRGKcrUip19GQuYTFkJxwAKwg
Date: Mon, 24 Nov 2014 17:09:46 +0000
Deferred-Delivery: Mon, 24 Nov 2014 17:09:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A77EEB@xmb-rcd-x01.cisco.com>
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> <547363C9.3090605@gmail.com>
In-Reply-To: <547363C9.3090605@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.22.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/hab_NmX8-MHt8DOicfJd4qooJzU
Cc: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>, Robert Moskowitz <rgm@htt-consult.com>
Subject: Re: [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 17:09:56 -0000

Yes, you made it clear that you do not like it, René. 

And certainly this is a clear indication that we should not generalize the mechanism beyond the proposal for the join process.

But we need 1) a plan B since the problem below is real and 2) convincing arguments against the particular use in the join process design.

In this particular use, the key (and the time slots) would be reserved for join only. There is no confidentiality there, and  whatever security properties will have to come from upper layer between the JN and the JCE.

There may be added work at upper layer to figure that an exchange happened on a join bundle (literally a different link from ULP perspective) and is thus not trusted, but I fail to see an opening that messages fully in the clear do not have already.

Cheers,

Pascal


> -----Original Message-----
> From: Rene Struik [mailto:rstruik.ext@gmail.com]
> Sent: lundi 24 novembre 2014 17:59
> To: Pascal Thubert (pthubert); Tero Kivinen; Michael Richardson
> Cc: Raghuram Sudhaakar (rsudhaak); 6tisch@ietf.org; Robert Moskowitz
> Subject: on the fallacy of default keys (was: Re: [6tisch] 6tisch join requirements
> for 6top)
> 
> 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