idnits 2.17.1
draft-richardson-6tisch-minimal-rekey-02.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 270 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 213 has weird spacing: '...address bin...'
== Line 263 has weird spacing: '... leaf counte...'
== 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 (August 28, 2017) is 2431 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 501, but no
explicit reference was found in the text
== Unused Reference: 'RFC7049' is defined on line 510, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-6tisch-6top-protocol' is defined on line
521, but no explicit reference was found in the text
== Outdated reference: A later version (-17) exists of
draft-ietf-core-comi-01
== Outdated reference: A later version (-16) exists of
draft-ietf-core-object-security-04
** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949)
== Outdated reference: A later version (-12) exists of
draft-ietf-6tisch-6top-protocol-07
== Outdated reference: A later version (-15) exists of
draft-ietf-6tisch-minimal-security-03
== Outdated reference: A later version (-10) exists of
draft-ietf-6tisch-terminology-09
== Outdated reference: A later version (-45) exists of
draft-ietf-anima-bootstrapping-keyinfra-07
Summary: 2 errors (**), 0 flaws (~~), 13 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 August 28, 2017
5 Expires: March 1, 2018
7 Minimal Security rekeying mechanism for 6TiSCH
8 draft-richardson-6tisch-minimal-rekey-02
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 March 1, 2018.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 3. Tree diagram notation . . . . . . . . . . . . . . . . . . . . 3
54 4. An approach to rekeying . . . . . . . . . . . . . . . . . . . 3
55 5. YANG models . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 5.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5
57 5.2. YANG model for keys . . . . . . . . . . . . . . . . . . . 5
58 5.3. YANG model for short-address . . . . . . . . . . . . . . 8
59 6. Security of CoMI link . . . . . . . . . . . . . . . . . . . . 10
60 7. Rekey of master connection . . . . . . . . . . . . . . . . . 10
61 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
64 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
66 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
67 12.2. Informative References . . . . . . . . . . . . . . . . . 12
68 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12
69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
71 1. Introduction
73 6TiSCH networks of nodes often use a pair of keys, K1/K2 to
74 authenticate beacons (K1), encrypt broadcast traffic (K1) and encrypt
75 unicast traffic (K2). These keys need to occasionally be refreshed
76 for a number of reasons:
78 o cryptographic hygiene: the keys must be replaced before the ASN
79 roles over or there could be repeated use of the same key.
81 o to remove nodes from the group: replacing the keys excludes any
82 nodes that are suspect, or which are known to have left the
83 network
85 o to recover short-addresses: if the JRC is running out of short
86 (2-byte) addresses, it can rekey the network in order to garbage
87 collect the set of addresses.
89 This protocol uses the CoMI [I-D.ietf-core-comi] to present the set
90 of 127 key pairs.
92 In addition to providing for rekey, this protocol includes access to
93 the allocated short-address.
95 2. Terminology
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in [RFC2119]. These
100 words may also appear in this document in lowercase, absent their
101 normative meanings.
103 The reader is expected to be familiar with the terms and concepts
104 defined in [I-D.ietf-6tisch-terminology], [RFC7252],
105 [I-D.ietf-core-object-security], and
106 [I-D.ietf-anima-bootstrapping-keyinfra].
108 3. Tree diagram notation
110 A simplified graphical representation of the data models is used in
111 this document. The meaning of the symbols in these diagrams is as
112 follows:
114 o Brackets "[" and "]" enclose list keys.
116 o Braces "{" and "}" enclose feature names, and indicate that the
117 named feature must be present for the subtree to be present.
119 o Abbreviations before data node names: "rw" (read-write) represents
120 configuration data and "ro" (read-only) represents state data.
122 o Symbols after data node names: "?" means an optional node, "!"
123 means a presence container, and "*" denotes a list and leaf-list.
125 o Parentheses enclose choice and case nodes, and case nodes are also
126 marked with a colon (":").
128 o Ellipsis ("...") stands for contents of subtrees that are not
129 shown.
131 4. An approach to rekeying
133 Rekeying of the network requires that all nodes be updated with the
134 new keys. This can take time as the network is constrained, and this
135 management traffic is not highest priority.
137 The JRC must reach out to all nodes that it is aware of. As the JRC
138 has originally provided the keys via either zero-touch
139 [I-D.ietf-6tisch-dtsecurity-secure-join] or
140 [I-D.ietf-6tisch-minimal-security] protocol, and in each case, the
141 JRC assigned the short-address to the node, so it knows about all the
142 nodes.
144 The data model presented in this document provides for up to 127 K1/
145 K2 keys, as each key requires a secKeyId, which is allocated from a
146 255-element palette provides by [IEEE8021542015]. Keys are to be
147 updated in pairs, and the pairs are associated in the following way:
148 the K1 key is always the odd numbered key (1,3,5), and the K2 key is
149 the even numbered key that follows (2,4,6). A secKeyId value of 0 is
150 invalid, and the secKeyId value of 255 is unused in this process.
152 Nodes MAY support up to all 127 key pair slots, but MUST support a
153 minimum of 6 keys (3 slot-pairs). When fewer than 127 are supported,
154 the node MUST support secKeyId values from 1 to 254 in a sparse array
155 fashion.
157 A particular key slot-pair is considered active, and this model
158 provides a mechanism to query and also to explicitely set the active
159 pair.
161 Nodes decrypt any packets for which they have keys, but MUST continue
162 to send using only the keypair which is considered active. Receipt
163 of a packet which is encrypted (or authenticated in the case of a
164 broadcast) with a secKeyId larger (taking consideration that secKeyId
165 wraps at 254) than the active slot-pair causes the node to change
166 active slot pairs.
168 This mechanism permits the JRC to provision new keys into all the
169 nodes while the network continues to use the existing keys. When the
170 JRC is certain that all (or enough) nodes have been provisioned with
171 the new keys, then the JRC causes a packet to be sent using the new
172 key. This can be the JRC sending the next Enhanced Beacon or unicast
173 traffic using the new key if the JRC is also a regular member of the
174 LLN. In the likely case that the JRC has no direct connection to the
175 LLN, then the JRC updates the active key to the new key pair using a
176 CoMI message.
178 The frame goes out with the new keys, and upon receipt (and
179 decryption) of the new frame all receiving nodes will switch to the
180 new active key. Beacons or unicast traffic leaving those nodes will
181 then update additional peers, and the network will switch over in a
182 flood-fill fashion.
184 ((EDNOTE: do we need an example?))
186 5. YANG models
187 5.1. Tree diagram
189 A diagram of the two YANG modules looks like:
191 1700 module: ietf-6tisch-symmetric-keying
192 1701 +--rw ietf6tischkeypairs* [counter]
193 1702 | +--rw counter uint16
194 1703 | +--rw ietf6tischkey1
195 1704 | | +--rw secKeyDescriptor
196 1705 | | | +--rw secKey? binary
197 1706 | | +--rw secKeyIndex? uint8
198 1707 | +--rw ietf6tischkey2
199 1708 | +--rw secKeyDescriptor
200 1709 | | +--rw secKey? binary
201 1710 | +--rw secKeyIndex? uint8
202 1711 +--ro secKeyUsage
203 1712 | +--ro txPacketsSent? uint32
204 1713 | +--ro rxPacketsSuccess? uint32
205 1714 | +--ro rxPacketsReceived? uint32
206 1715 +--rw newKey? binary
208 rpcs:
209 1716 +---x installNextKey
211 1717 module: ietf-6tisch-short-address
212 1718 +--ro ietf6shortaddresses
213 1719 +--ro shortaddress binary
214 1720 +--ro validuntil uint32
215 1721 +--ro effectiveat? uint32
217 Figure 1: Tree diagrams of two rekey modules
219 5.2. YANG model for keys
221 module ietf-6tisch-symmetric-keying {
222 yang-version 1.1;
224 namespace
225 "urn:ietf:params:xml:ns:yang:ietf-6tisch-symmetric-keying";
226 prefix "ietf6keys";
228 //import ietf-yang-types { prefix yang; }
229 //import ietf-inet-types { prefix inet; }
231 organization
232 "IETF 6tisch Working Group";
234 contact
235 "WG Web:
236 WG List:
237 Author: Michael Richardson
238 ";
240 description
241 "This module defines the format for a set of network-wide 802.15.4
242 keys used in 6tisch networks. There are 128 sets of key pairs,
243 with one keypair (K1) used to authenticate (and sometimes encrypt)
244 multicast traffic, and another keypair (K2) used to encrypt unicast
245 traffic. The 128 key pairs are numbered by the (lower) odd
246 keyindex, which otherwise is a 0-255 value. Keyindex 0 is
247 not valid. This module is a partial expression of the tables in
248 https://mentor.ieee.org/802.15/dcn/15/15-15-0106-07-0mag-security-section-pictures.pdf.
249 To read and write the key pairs, a monotonically increasing counter is added. A new key pair must be added with current_counter = last_counter+1. The current specification allows overwriting of earlier key pairs. It is up to the server to remove old key pairs, such that only the last three (two) pairs are stored and visible to the client.";
251 revision "2017-03-01" {
252 description
253 "Initial version";
254 reference
255 "RFC XXXX: 6tisch minimal security";
256 }
258 // list of key pairs
259 list ietf6tischkeypairs {
260 key counter;
261 description
262 "a list of key pairs with unique index: counter.";
263 leaf counter {
264 type uint16{
265 range "0..256"; // for the moment 256 items
266 }
267 mandatory "true";
268 description
269 "unique reference to the key pair for client access.";
270 } // counter
272 // key descriptor for FIRST part of pair
273 container ietf6tischkey1 {
274 description
275 "A voucher that can be used to assign one or more
276 devices to an owner.";
277 // this container is pretty empty, a leaf would do the job.
279 container secKeyDescriptor {
280 // I assume this needs to be extended, why else a container?
281 description
282 "This container describes the details of a
283 specific cipher key";
284 leaf secKey {
285 type binary;
286 description "The actual encryption key.
287 This value is write only, and is not returned in a
288 read, or returns all zeroes.";
289 } // secKey
290 } // secKeyDescriptor
292 // leaf secKeyIdMode is always 1, not described here.
293 leaf secKeyIndex {
294 type uint8;
295 description
296 "The keyIndex for this keySet.
297 A number between 1 and 255.";
298 reference
299 "IEEE802.15.4";
300 } // secKeyIndex
301 } // ietf6tischkey1
303 // key descriptor for SECOND part of pair
304 container ietf6tischkey2 {
305 description
306 "A voucher that can be used to assign one or more
307 devices to an owner.";
308 container secKeyDescriptor {
309 // I assume this needs to be extended, why else a container?
310 description
311 "This container describes the details of a
312 specific cipher key";
313 leaf secKey {
314 type binary;
315 description "The actual encryption key.
316 This value is write only, and is not returned in a
317 read, or returns all zeroes.";
318 } // secKey
319 } // secKeyDescriptor
321 // leaf secKeyIdMode is always 1, not described here.
322 leaf secKeyIndex {
323 type uint8;
324 description
325 "The keyIndex for this keySet.
326 A number between 1 and 255.";
327 reference
328 "IEEE802.15.4";
329 } // secKeyIndex
331 } // ietf6tischkey2
332 } //ietf6tischkeypairs
334 // the usage is over all pairs
335 container secKeyUsage {
336 config false; // cannot be set by client
337 description
338 "statistics of sent and received packets.";
339 leaf txPacketsSent {
340 type uint32;
341 description "Number of packets sent with this key.";
342 } // txPacketsSent
343 leaf rxPacketsSuccess {
344 type uint32;
345 description "Number of packets received with this key that were
346 successfully decrypted and authenticated.";
347 }// rxPacketsSuccess
348 leaf rxPacketsReceived {
349 type uint32;
350 description "Number of packets received with this key, both
351 successfully received, and unsuccessfully.";
352 } // rxPacketsReceived
354 } // secKeyUsage
356 // setting new key, and validation of new key
357 leaf newKey{
358 type binary;
359 description
360 "new key value to be set by client.";
361 } // newKey
362 rpc installNextKey{
363 description
364 "Client informs server that newKey is to be
365 used as current key.";
366 } // installNextKey
368 } // module ietf-6tisch-symmetric-keying
370 5.3. YANG model for short-address
372 module ietf-6tisch-short-address {
373 yang-version 1.1;
375 namespace
376 "urn:ietf:params:xml:ns:yang:ietf-6tisch-short-address";
377 prefix "ietf6shortaddr";
378 //import ietf-yang-types { prefix yang; }
379 //import ietf-inet-types { prefix inet; }
381 organization
382 "IETF 6tisch Working Group";
384 contact
385 "WG Web:
386 WG List:
387 Author: Michael Richardson
388 ";
390 description
391 "This module defines an interface to set and interrogate
392 the short (16-bit) layer-2 address used in 802.15.4
393 TSCH mode networks. The short addresses are used
394 in L2 frames to save space. A lifetime is included
395 in terms of TSCH Absolute Slot Number, which acts
396 as a monotonically increasing clock. ";
398 revision "2017-03-01" {
399 description
400 "Initial version";
401 reference
402 "RFC XXXX: 6tisch minimal security";
403 }
405 // top-level container
406 container ietf6shortaddresses {
407 config false;
408 description
409 "A 16-bit short address for use by the node.";
411 leaf shortaddress {
412 type binary{
413 length 1..2;}
414 mandatory true;
415 description
416 "The two byte short address to be set.";
417 }
418 leaf validuntil {
419 type uint32;
420 mandatory true;
421 description "The Absolute Slot Number/256 at which
422 the address ceases to be valid.";
423 }
425 leaf effectiveat {
426 type uint32;
427 description "The Absolute Slot Number/256 at which
428 time the address was originally set.
429 This is a read-only attribute that
430 records the ASN when the shortaddress
431 element was last written or updated.";
432 }
433 }
434 }
436 6. Security of CoMI link
438 The CoMI resources presented here are protected by OSCOAP
439 ([I-D.ietf-core-object-security]), secured using the EDHOC connection
440 used for joining. A unique application key is generated using an
441 additional key generation process with the unique label "6tisch-
442 rekey".
444 7. Rekey of master connection
446 Should the OSCOAP connection need to be rekeyed, a new EDHOC process
447 will be necessary. This will need access to trusted authentication
448 keys, either the PSK used from a one-touch process, or the locally
449 significant domain certificates installed during a zero-touch
450 process.
452 8. Privacy Considerations
454 The rekey protocol itself runs over a network encrypted with the K2
455 key. The end to end protocol from JRC to node is also encrypted
456 using OSCOAP, so the keys are not visible, nor is the keying traffic
457 distinguished in anyway to an observer.
459 As the secKeyId is not confidential in the underlying 802.15.4
460 frames, an observer can determine what sets of keys are in use, and
461 when a rekey is activated by observing the change in the secKeyId.
463 The absolute value of the monitonically increasing secKeyId could
464 provide some information as to the age of the network.
466 9. Security Considerations
468 This protocol permits the underlying network keys to be set. Access
469 to all of the portions of this interface MUST be restricted to an
470 ultimately trusted peer, such as the JRC.
472 An implementation SHOULD not permit reading the network keys. Those
473 fields should be write-only.
475 The OSCOAP security for this interface is initialized by a join
476 mechanism, and so depends upon the initial credentials provided to
477 the node. The initial network keys would have been provided during
478 the join process; this protocol permits them to be updated.
480 10. IANA Considerations
482 This document allocates a SID number for the YANG model. There is no
483 IANA action required for this document.
485 11. Acknowledgments
487 12. References
489 12.1. Normative References
491 [I-D.ietf-core-comi]
492 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
493 Management Interface", draft-ietf-core-comi-01 (work in
494 progress), July 2017.
496 [I-D.ietf-core-object-security]
497 Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
498 "Object Security of CoAP (OSCOAP)", draft-ietf-core-
499 object-security-04 (work in progress), July 2017.
501 [I-D.ietf-cose-msg]
502 Schaad, J., "CBOR Object Signing and Encryption (COSE)",
503 draft-ietf-cose-msg-24 (work in progress), November 2016.
505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
506 Requirement Levels", BCP 14, RFC 2119,
507 DOI 10.17487/RFC2119, March 1997, .
510 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
511 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
512 October 2013, .
514 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
515 Application Protocol (CoAP)", RFC 7252,
516 DOI 10.17487/RFC7252, June 2014, .
519 12.2. Informative References
521 [I-D.ietf-6tisch-6top-protocol]
522 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
523 (6P)", draft-ietf-6tisch-6top-protocol-07 (work in
524 progress), June 2017.
526 [I-D.ietf-6tisch-dtsecurity-secure-join]
527 Richardson, M., "6tisch Secure Join protocol", draft-ietf-
528 6tisch-dtsecurity-secure-join-01 (work in progress),
529 February 2017.
531 [I-D.ietf-6tisch-minimal-security]
532 Vucinic, M., Simon, J., Pister, K., and M. Richardson,
533 "Minimal Security Framework for 6TiSCH", draft-ietf-
534 6tisch-minimal-security-03 (work in progress), June 2017.
536 [I-D.ietf-6tisch-terminology]
537 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
538 "Terminology in IPv6 over the TSCH mode of IEEE
539 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
540 progress), June 2017.
542 [I-D.ietf-anima-bootstrapping-keyinfra]
543 Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
544 S., and K. Watsen, "Bootstrapping Remote Secure Key
545 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
546 keyinfra-07 (work in progress), July 2017.
548 [IEEE8021542015]
549 IEEE standard for Information Technology, ., "IEEE Std
550 802.15.4-2015 Standard for Low-Rate Wireless Personal Area
551 Networks (WPANs)", 2015.
553 Appendix A. Example
555 In the examples below, a new key value is set in the server
556 example.com; followed by the setting of the new key value as the
557 current key value. The SID values of new Key and installNextKey are
558 1715 and 1716 respectively. The corresponding base64 values are: ez
559 and e0 respectively.
561 The setting of the new key value is done with the PUT request with
562 the binary value 1234567890.
564 PUT coap://example.com/c/ez
565 (Content-Format :application/yang-value+cbor)
566 h'1234567890'
568 RES: 2.01 Created
570 Payload in CBOR:
571 45 # bytes(5)
572 1234567890 # "\x124Vx\x90"
574 Consecutively, the RPC is invoked with a POST method to validate the
575 new key value.
577 POST coap://example.com/c/e0
578 (Content-Format :application/yang-value+cbor)
580 RES: 2.05 Content
582 The client can query how many TX packets have been received. The SID
583 of secKeyUsage/txPacketsSent is 1712, corresponding with base64 ew.
585 GET coap://example.com/c/ew
587 RES: 2.05 Content (Content-Format :application/yang-value+cbor)
588 3
590 Payload in CBOR:
591 03 # unsigned(3)
593 Author's Address
595 Michael Richardson
596 Sandelman Software Works
598 Email: mcr+ietf@sandelman.ca