Re: [6tisch] 6tisch join requirements for 6top
Pat Kinney <pat.kinney@kinneyconsultingllc.com> Mon, 24 November 2014 17:32 UTC
Return-Path: <pat.kinney@kinneyconsultingllc.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 926D21A854B for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 09:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 O5hTMUtB5Mit for <6tisch@ietfa.amsl.com>; Mon, 24 Nov 2014 09:32:19 -0800 (PST)
Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC71A8748 for <6tisch@ietf.org>; Mon, 24 Nov 2014 09:32:19 -0800 (PST)
Received: from [10.0.1.55] ([67.175.93.172]) by p3plsmtpa07-04.prod.phx3.secureserver.net with id KVYG1p00N3j83aT01VYG7x; Mon, 24 Nov 2014 10:32:19 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Pat Kinney <pat.kinney@kinneyconsultingllc.com>
In-Reply-To: <21619.12717.53454.214321@fireball.kivinen.iki.fi>
Date: Mon, 24 Nov 2014 11:32:15 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4B72292-0BDE-406D-94A0-C7D173C40B7D@kinneyconsultingllc.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>
To: Tero Kivinen <kivinen@IKI.FI>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/e9hfh-j5IVpJwsMRzMD2pFsIp80
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6tisch@ietf.org, Robert Moskowitz <rgm@htt-consult.com>, "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>
Subject: Re: [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 17:32:21 -0000
I find that I must disagree with Tero on his point 10 the well-known beacon key to use for the join network. (Defaulting to "6TISCHJOIN). This behavior is used in WirelessHART networks for a very practical reason. Keys are not always used for security purposes, often they are used to prevent unintended occurrences, like using a lock and key to prevent a door from accidentally opening. It is for this reasoning that WirelessHART used a "well-known" key (772E 6861 7274 636F 6D6D 2E6F 7267: ASCII value sequence of the 16 character string of the HART Foundation's web address: www.hartcomm.org) for nodes joining a network or broadcasting a network advertisement. This mechanism allows for the 802.15.4 MAC to perform additional filtering on received packets. It was noted in large conventions that using only the 2-octet FCS filter was not sufficient to prevent all undesired messages. Using the well-known key allowed an additional filter of the 4-octet MIC. In conclusion, I support the use of the well-known key and I further disagree with the comment that "Using well-known keys makes it bit harder for the upper layer to know whether the frame actually has some protection or not", if an upper layer finds this practice confusing then it shouldn't be an upper layer, perhaps it should try out as a PHY. Pat Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 pat.kinney@kinneyconsultingllc.com On 24, Nov2014, at 7:25, Tero Kivinen <kivinen@IKI.FI> wrote: 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 mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
- [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