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