[6tisch] 6tisch join requirements for 6top
Tero Kivinen <kivinen@iki.fi> Mon, 24 November 2014 13:25 UTC
Return-Path: <kivinen@iki.fi>
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 A05B21A6F2D for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 05:25:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.368
X-Spam-Level: *
X-Spam-Status: No, score=1.368 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_51=0.6, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 p1gBd6wtVL_d for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 05:25:31 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA471A6F34 for <6tisch@ietf.org>; Mon, 24 Nov 2014 05:25:30 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sAODP2is002960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Nov 2014 15:25:02 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sAODP1fD014202; Mon, 24 Nov 2014 15:25:01 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21619.12717.53454.214321@fireball.kivinen.iki.fi>
Date: Mon, 24 Nov 2014 15:25:01 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <8193.1416253349@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>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 101 min
X-Total-Time: 69 min
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/d3BY3hrifdVSLyTtjlFyyAvimiQ
X-Mailman-Approved-At: Mon, 24 Nov 2014 05:36:18 -0800
Cc: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>, 6tisch@ietf.org, Robert Moskowitz <rgm@htt-consult.com>
Subject: [6tisch] 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 13:25:33 -0000
Michael Richardson writes: > joining node interface: > 1) an enum (registry) saying what kind of network security is to be used. > a) NO_SECURITY = 0 > b) network-wide MIC/key, to be used directly. As the key is AES-CCM key that means that every single device needs to store their frame counters to stable storage. This sets quite high requirements for the devices. In theory they should also store the frame counters for all the peers they are talking to, but I don't know if any device does that. Usually they only store their own frame counter to flash every now and then, and then on the restart they load it from the flash, and add big enough counter to it to make sure that it is unique. > c) a network-wide "PSK", to be used with 802.15.9 mode DTLS (DHE_PSK), > unclear to me how broadcast/multicasts are keyed,I hope to read > the 15.9 documents. There is no TLS/DTLS key management defined in the 15.9. Nobody has bothered to invest time or energy to add that, so thats why it is not there. > d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2 > (Shared key message integrity code. ditto about broadcast) How the broadcast/multicast keys are keyed is not really defined in the 15.9, but it is left for the upper layer. I.e. 15.4 the keys are identified with the two attributes, Key Source and Key Index. The format of the Key Source depends on the Key Identifier Mode value. There are 4 different values for the Key Identifier Mode: 0x00 Key is determined implictly from the originator and recipient(s) of the frame. I.e there is no Key Source or Key Index, and pairwise keys between peers are used. Note, that there is no Key Index, thus there is only one such key at given time. 0x01 Key is determined from the Key Index field in conjuction with macDefaultKeySource. I.e. each device can have one default sender, which allows compression of the security header, as this default key source can be left out from the header. I would expect that this macDefaultKeySource would be the PAN coordinator or similar. As the macDefaultKeySource needs to be global to the PAN, there can really be only one owner for the key. 0x02 Key is determined explictly from the 4-octet Key Source field, and the Key Index field. The 4-octet Key Source consists of PAN Id and the short address. I.e there can be 255 keys from the same sender. 0x03 Key is determined explictly from the 8-octet key source field, and the key index field. I.e. this gives the extended address of the sender and identifies which of the 255 keys from that sender is used. The 15.9 allows creating those keys KMP-CREATE.request is given the NewKeyIdMode, NewKeySource and NewKeyIndex which key management then negotiates. If the NewKeyIdMode is 0x00, then pairwise keys are negotiated, and there can only be one key between the peers, so the Key Source and Key Index are ignored. The key identifier mode 0x01 can be used for the broadcast key for the traffic originating from the pan coordinator. I.e. instead of storing the pan coordinator address in the header, it can be left out, but as one common frame counter is used for all traffic, only the pan coordinator (or actually the macDefaultKeySource, i.e. the owner of the key) can send data out using this key. The key identifier modes 0x02 and 0x03 can be used for the broadcast or multicast traffic from any peer to any peer. Each originator has its own frame counters and each recipient stores last frame counter seen from the other enad compares that there is no replay. All of those keys can be negotiated by the upper layer, by calling the KMP-CREATE.request with suitable paramaters. How the actual key management protocol then maps those calls to actual operations on the key management is left outside the 15.9. I.e. we most likely need IETF draft explaining how to map the KeyIdMode, KeySource and KeyIndex to actual IKEv2/HIP etc payloads. For pairwise keys this is usually quite easy, i.e. we just derive those keys from the KEYMAT. This is actually defined in the 15.9. For the broadcast / multicast key destribition it says that such features needs to be added to the IKEv2, i.e. sending key material over IKEv2 channel using Notify payloads inside INFORMATIONAL exchanges. I.e. we need to write draft saying that 15.9 broadcast/multicast key distribution is done by sending Notify Payload with notify message status type of xxx, and having content of: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |KIM| RESERVED | Key Source (0/4/8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Key Index | Key Material (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the KIM is the Key Id Mode, and the Key Source is either 0, 4, or 8 octects depeding on the KIM value (0x01 = 0, 0x02 = 4, 0x03 = 8 octets). The Key Index is always 1 octet. This is never used if the Key Id Mode is 0, as then pairwise keys are used. The Key material used for the key is the last 16 octets of the notify payload. This specification is not yet written. Or instead of that we can use the GDOI IKEv2 specification to distribute the keying material. > f) a PK method: to be used with 802.15.9 mode DTLS (ECDSA), As I said no DTLS/TLS key management method in 15.9. If that is needed, then someone needs to start working on it, i.e. write the appendix for it. > g) a PK method: to be used with 802.15.9 mode IKEv2 (ECDSA) > I thought that 7296 would have rolled in the signature-auth work. > I want to specify the ECDSA authentication methods. The 7296 didn't include signature auth method draft, as there was not yet proven interoperability with it. There are not even implementations out there using it yet, so to make that full internet standard in the first step would have been bit premature. It should come out as RFC soon. > h) ditto above, s/IKEv2/HIP/ > i) perhaps a code for using draft-piro-6tisch-security-issues-02 > -- I'm unclear how MLE works at this point. > > 2) a space for an ECDSA PKIX certificate. from 6top's point of view, this is > around 300 opaque bytes. We should be transfering DER, not base64 encoded > certificates! 802.15.9 allows transmitting 9 kB payloads inside the 15.4, so 300 bytes should not be problem. Also 15.9 defines multipurpose layer, which can be used by others than KMP, i.e. 6tisch can use it do its own protocols if needed. > 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. -- kivinen@iki.fi
- [6tisch] CoAP resource management - draft-ietf-6t… Raghuram Sudhaakar (rsudhaak)
- Re: [6tisch] CoAP resource management - draft-iet… Michael Richardson
- Re: [6tisch] CoAP resource management - draft-iet… Carsten Bormann
- Re: [6tisch] CoAP resource management - draft-iet… Raghuram Sudhaakar (rsudhaak)
- Re: [6tisch] CoAP resource management - draft-iet… Michael Richardson
- Re: [6tisch] CoAP resource management - draft-iet… Thomas Watteyne
- Re: [6tisch] CoAP resource management - draft-iet… Pascal Thubert (pthubert)
- [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Xavier Vilajosana
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Pascal Thubert (pthubert)
- [6tisch] on the fallacy of default keys (was: Re:… Rene Struik
- Re: [6tisch] on the fallacy of default keys (was:… Pascal Thubert (pthubert)
- Re: [6tisch] on the fallacy of default keys Rene Struik
- Re: [6tisch] 6tisch join requirements for 6top Pat Kinney
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Pascal Thubert (pthubert)
- Re: [6tisch] 6tisch join requirements for 6top Kris Pister
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- [6tisch] emails on 802.15.4 specs Rene Struik
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top yoshihiro.ohba
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne
- Re: [6tisch] 6tisch join requirements for 6top Carsten Bormann
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top yoshihiro.ohba
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top dejichen
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne