idnits 2.17.1
draft-richardson-6tisch-minimal-rekey-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 2 instances of too long lines in the document, the longest one
being 20 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
An implementation SHOULD not permit reading the network keys.
Those fields should be write-only.
-- The document date (February 25, 2017) is 2615 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'I-D.ietf-cose-msg' is defined on line 399, but no
explicit reference was found in the text
== Unused Reference: 'RFC7049' is defined on line 408, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-6tisch-6top-protocol' is defined on line
419, but no explicit reference was found in the text
== Outdated reference: A later version (-17) exists of
draft-ietf-core-comi-00
== Outdated reference: A later version (-16) exists of
draft-ietf-core-object-security-01
** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949)
== Outdated reference: A later version (-12) exists of
draft-ietf-6tisch-6top-protocol-03
== Outdated reference: A later version (-01) exists of
draft-ietf-6tisch-dtsecurity-secure-join-00
== Outdated reference: A later version (-15) exists of
draft-ietf-6tisch-minimal-security-01
== Outdated reference: A later version (-10) exists of
draft-ietf-6tisch-terminology-08
== Outdated reference: A later version (-45) exists of
draft-ietf-anima-bootstrapping-keyinfra-04
Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 6TiSCH Working Group M. Richardson
3 Internet-Draft Sandelman Software Works
4 Intended status: Standards Track February 25, 2017
5 Expires: August 29, 2017
7 Minimal Security rekeying mechanism for 6TiSCH
8 draft-richardson-6tisch-minimal-rekey-01
10 Abstract
12 This draft describes a mechanism to rekey the networks used by 6TISCH
13 nodes. It leverages the security association created during an
14 enrollment protocol. The rekey mechanism permits incremental
15 deployment of new sets of keys, followed by a rollover to a new key.
17 Status of This Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on August 29, 2017.
34 Copyright Notice
36 Copyright (c) 2017 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
53 3. An approach to rekeying . . . . . . . . . . . . . . . . . . . 3
54 4. YANG model for keys . . . . . . . . . . . . . . . . . . . . . 4
55 5. YANG model for short-address . . . . . . . . . . . . . . . . 6
56 6. Security of CoMI link . . . . . . . . . . . . . . . . . . . . 8
57 7. Rekey of master connection . . . . . . . . . . . . . . . . . 8
58 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
61 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
63 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
64 12.2. Informative References . . . . . . . . . . . . . . . . . 9
65 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10
66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
68 1. Introduction
70 6TiSCH networks of nodes often use a pair of keys, K1/K2 to
71 authenticate beacons (K1), encrypt broadcast traffic (K1) and encrypt
72 unicast traffic (K2). These keys need to occasionally be refreshed
73 for a number of reasons:
75 o cryptographic hygiene: the keys must be replaced before the ASN
76 roles over or there could be repeated use of the same key.
78 o to remove nodes from the group: replacing the keys excludes any
79 nodes that are suspect, or which are known to have left the
80 network
82 o to recover short-addresses: if the JRC is running out of short
83 (2-byte) addresses, it can rekey the network in order to garbage
84 collect the set of addresses.
86 This protocol uses the CoMI [I-D.ietf-core-comi] to present the set
87 of 127 key pairs.
89 In addition to providing for rekey, this protocol includes access to
90 the allocated short-address.
92 2. Terminology
94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
96 document are to be interpreted as described in [RFC2119]. These
97 words may also appear in this document in lowercase, absent their
98 normative meanings.
100 The reader is expected to be familiar with the terms and concepts
101 defined in [I-D.ietf-6tisch-terminology], [RFC7252],
102 [I-D.ietf-core-object-security], and
103 [I-D.ietf-anima-bootstrapping-keyinfra].
105 3. An approach to rekeying
107 Rekeying of the network requires that all nodes be updated with the
108 new keys. This can take time as the network is constrained, and this
109 management traffic is not highest priority.
111 The JRC must reach out to all nodes that it is aware of. As the JRC
112 has originally provided the keys via either zero-touch
113 [I-D.ietf-6tisch-dtsecurity-secure-join] or
114 [I-D.ietf-6tisch-minimal-security] protocol, and in each case, the
115 JRC assigned the short-address to the node, so it knows about all the
116 nodes.
118 The data model presented in this document provides for up to 127 K1/
119 K2 keys, as each key requires a secKeyId, which is allocated from a
120 255-element palette provides by [IEEE8021542015]. Keys are to be
121 updated in pairs, and the pairs are associated in the following way:
122 the K1 key is always the odd numbered key (1,3,5), and the K2 key is
123 the even numbered key that follows (2,4,6). A secKeyId value of 0 is
124 invalid, and the secKeyId value of 255 is unused in this process.
126 Nodes MAY support up to all 127 key pair slots, but MUST support a
127 minimum of 6 keys (3 slot-pairs). When fewer than 127 are supported,
128 the node MUST support secKeyId values from 1 to 254 in a sparse array
129 fashion.
131 A particular key slot-pair is considered active, and this model
132 provides a mechanism to query and also to explicitely set the active
133 pair.
135 Nodes decrypt any packets for which they have keys, but MUST continue
136 to send using only the keypair which is considered active. Receipt
137 of a packet which is encrypted (or authenticated in the case of a
138 broadcast) with a secKeyId larger (taking consideration that secKeyId
139 wraps at 254) than the active slot-pair causes the node to change
140 active slot pairs.
142 This mechanism permits the JRC to provision new keys into all the
143 nodes while the network continues to use the existing keys. When the
144 JRC is certain that all (or enough) nodes have been provisioned with
145 the new keys, then the JRC causes a packet to be sent using the new
146 key. This can be the JRC sending the next Enhanced Beacon or unicast
147 traffic using the new key if the JRC is also a regular member of the
148 LLN. In the likely case that the JRC has no direct connection to the
149 LLN, then the JRC updates the active key to the new key pair using a
150 CoMI message.
152 The frame goes out with the new keys, and upon receipt (and
153 decryption) of the new frame all receiving nodes will switch to the
154 new active key. Beacons or unicast traffic leaving those nodes will
155 then update additional peers, and the network will switch over in a
156 flood-fill fashion.
158 ((EDNOTE: do we need an example?))
160 4. YANG model for keys
162 module ietf-6tisch-symmetric-keying {
163 yang-version 1.1;
165 namespace
166 "urn:ietf:params:xml:ns:yang:6tisch-keys";
167 prefix "ietf6keys";
169 //import ietf-yang-types { prefix yang; }
170 //import ietf-inet-types { prefix inet; }
172 organization
173 "IETF 6tisch Working Group";
175 contact
176 "WG Web:
177 WG List:
178 Author: Michael Richardson
179 ";
181 description
182 "This module defines the format for a set of network-wide 802.15.4
183 keys used in 6tisch networks. There are 128 sets of key pairs,
184 with one keypair (K1) used to authenticate (and sometimes encrypt)
185 multicast traffic, and another keypair (K2) used to encrypt unicast
186 traffic. The 128 key pairs are numbered by the (lower) odd
187 keyindex, which otherwise is a 0-255 value. Keyindex 0 is
188 not valid. This module is a partial expression of the tables in
189 https://mentor.ieee.org/802.15/dcn/15/15-15-0106-07-0mag-security-section-pictures.pdf";
191 revision "2017-03-01" {
192 description
193 "Initial version";
194 reference
195 "RFC XXXX: 6tisch minimal security";
196 }
198 // top-level container
199 container ietf6tischkeys {
200 config false;
201 description
202 "A voucher that can be used to assign one or more
203 devices to an owner.";
205 // secKeyIdMode is always 1, do not describe it here.
206 leaf secKeyIndex {
207 type uint8;
208 description
209 "The keyIndex for this keySet. A number between 1 and 255.";
211 reference
212 "IEEE802.15.4";
213 }
215 container secKeyUsage {
216 leaf txPacketsSent {
217 type uint32;
218 description "Number of packets sent with this key.";
219 }
220 leaf rxPacketsSuccess {
221 type uint32;
222 description "Number of packets received with this key that were
223 successfully decrypted and authenticated.";
224 }
225 leaf rxPacketsReceived {
226 type uint32;
227 description "Number of packets received with this key, both
228 successfully received, and unsuccessfully.";
229 }
231 }
233 container secKeyDescriptor {
234 description
235 "This container describes the details of a specific cipher key";
236 leaf secKey {
237 type binary;
238 description "The actual encryption key.
239 This value is write only, and is not returned in a
240 read, or returns all zeroes.";
242 }
243 }
244 }
245 }
247 5. YANG model for short-address
249 module ietf-6tisch-symmetric-keying {
250 yang-version 1.1;
252 namespace
253 "urn:ietf:params:xml:ns:yang:6tisch-keys";
254 prefix "ietf6keys";
256 //import ietf-yang-types { prefix yang; }
257 //import ietf-inet-types { prefix inet; }
259 organization
260 "IETF 6tisch Working Group";
262 contact
263 "WG Web:
264 WG List:
265 Author: Michael Richardson
266 ";
268 description
269 "This module defines the format for a set of network-wide
270 802.15.4 keys used in 6tisch networks. There are 128
271 sets of key pairs, with one keypair (K1) used to
272 authenticate (and sometimes encrypt) multicast traffic,
273 and another keypair (K2) used to encrypt unicast traffic.
274 The 128 key pairs are numbered by the (lower) odd
275 keyindex, which otherwise is a 0-255 value.
276 Keyindex 0 is not valid. This module is a partial
277 expression of the tables in
278 https://mentor.ieee.org/802.15/dcn/15/15-15-0106-07-0mag-security-section-pictures.pdf";
280 revision "2017-03-01" {
281 description
282 "Initial version";
283 reference
284 "RFC XXXX: 6tisch minimal security";
285 }
287 // top-level container
288 container ietf6tischkeys {
289 config false;
290 description
291 "A voucher that can be used to assign one or more
292 devices to an owner.";
294 // secKeyIdMode is always 1, do not describe it here.
295 leaf secKeyIndex {
296 type uint8;
297 description
298 "The keyIndex for this keySet. A number between
299 1 and 255.";
301 reference
302 "IEEE802.15.4";
303 }
305 container secKeyUsage {
306 leaf txPacketsSent {
307 type uint32;
308 description "Number of packets sent with this key.";
309 }
310 leaf rxPacketsSuccess {
311 type uint32;
312 description "Number of packets received with this key
313 that were successfully decrypted and authenticated.";
314 }
315 leaf rxPacketsReceived {
316 type uint32;
317 description "Number of packets received with this key,
318 both successfully received, and unsuccessfully.";
319 }
321 }
323 container secKeyDescriptor {
324 description
325 "This container describes the details of a specific
326 cipher key";
327 leaf secKey {
328 type binary;
329 description "The actual encryption key";
330 }
331 }
332 }
333 }
334 6. Security of CoMI link
336 The CoMI resources presented here are protected by OSCOAP
337 ([I-D.ietf-core-object-security]), secured using the EDHOC connection
338 used for joining. A unique application key is generated using an
339 additional key generation process with the unique label "6tisch-
340 rekey".
342 7. Rekey of master connection
344 Should the OSCOAP connection need to be rekeyed, a new EDHOC process
345 will be necessary. This will need access to trusted authentication
346 keys, either the PSK used from a one-touch process, or the locally
347 significant domain certificates installed during a zero-touch
348 process.
350 8. Privacy Considerations
352 The rekey protocol itself runs over a network encrypted with the K2
353 key. The end to end protocol from JRC to node is also encrypted
354 using OSCOAP, so the keys are not visible, nor is the keying traffic
355 distinguished in anyway to an observer.
357 As the secKeyId is not confidential in the underlying 802.15.4
358 frames, an observer can determine what sets of keys are in use, and
359 when a rekey is activated by observing the change in the secKeyId.
361 The absolute value of the monitonically increasing secKeyId could
362 provide some information as to the age of the network.
364 9. Security Considerations
366 This protocol permits the underlying network keys to be set. Access
367 to all of the portions of this interface MUST be restricted to an
368 ultimately trusted peer, such as the JRC.
370 An implementation SHOULD not permit reading the network keys. Those
371 fields should be write-only.
373 The OSCOAP security for this interface is initialized by a join
374 mechanism, and so depends upon the initial credentials provided to
375 the node. The initial network keys would have been provided during
376 the join process; this protocol permits them to be updated.
378 10. IANA Considerations
380 This document allocates a SID number for the YANG model. There is no
381 IANA action required for this document.
383 11. Acknowledgments
385 12. References
387 12.1. Normative References
389 [I-D.ietf-core-comi]
390 Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP
391 Management Interface", draft-ietf-core-comi-00 (work in
392 progress), January 2017.
394 [I-D.ietf-core-object-security]
395 Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
396 "Object Security of CoAP (OSCOAP)", draft-ietf-core-
397 object-security-01 (work in progress), December 2016.
399 [I-D.ietf-cose-msg]
400 Schaad, J., "CBOR Object Signing and Encryption (COSE)",
401 draft-ietf-cose-msg-24 (work in progress), November 2016.
403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
404 Requirement Levels", BCP 14, RFC 2119,
405 DOI 10.17487/RFC2119, March 1997,
406 .
408 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
409 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
410 October 2013, .
412 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
413 Application Protocol (CoAP)", RFC 7252,
414 DOI 10.17487/RFC7252, June 2014,
415 .
417 12.2. Informative References
419 [I-D.ietf-6tisch-6top-protocol]
420 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
421 ietf-6tisch-6top-protocol-03 (work in progress), October
422 2016.
424 [I-D.ietf-6tisch-dtsecurity-secure-join]
425 Richardson, M., "6tisch Secure Join protocol", draft-ietf-
426 6tisch-dtsecurity-secure-join-00 (work in progress),
427 December 2016.
429 [I-D.ietf-6tisch-minimal-security]
430 Vucinic, M., Simon, J., and K. Pister, "Minimal Security
431 Framework for 6TiSCH", draft-ietf-6tisch-minimal-
432 security-01 (work in progress), February 2017.
434 [I-D.ietf-6tisch-terminology]
435 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
436 "Terminology in IPv6 over the TSCH mode of IEEE
437 802.15.4e", draft-ietf-6tisch-terminology-08 (work in
438 progress), December 2016.
440 [I-D.ietf-anima-bootstrapping-keyinfra]
441 Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
442 S., and K. Watsen, "Bootstrapping Remote Secure Key
443 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
444 keyinfra-04 (work in progress), October 2016.
446 [IEEE8021542015]
447 IEEE standard for Information Technology, ., "IEEE Std
448 802.15.4-2015 Standard for Low-Rate Wireless Personal Area
449 Networks (WPANs)", 2015.
451 Appendix A. Example
453 Example COMI requests/responses.
455 Author's Address
457 Michael Richardson
458 Sandelman Software Works
460 Email: mcr+ietf@sandelman.ca