idnits 2.17.1 draft-struik-6tisch-security-architecture-elements-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-coap' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-6tisch-6top-sublayer' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-6top-interface' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'I-D.garcia-core-security' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dice-profile' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'I-D.kumar-dice-dtls-relay' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'IEEE802.15.4-2011' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'IEEE802.15.4e-2012' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'Wireless-HART' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'ZigBee-IP' is defined on line 413, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-02 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-17) exists of draft-ietf-dice-profile-01 == Outdated reference: A later version (-02) exists of draft-kumar-dice-dtls-relay-01 Summary: 2 errors (**), 0 flaws (~~), 24 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH R. Struik 3 Internet-Draft Struik Security Consultancy 4 Intended status: Informational July 4, 2014 5 Expires: January 5, 2015 7 6TiSCH Security Architectural Elements 8 draft-struik-6tisch-security-architecture-elements-00 10 Abstract 12 This document describes security architectural elements that are 13 relevant for the design of the 6TiSCH security architecture. (Note: 14 this document is a work-in-progress and will provide more fine-tuned 15 information with updated versions.) 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 21 "OPTIONAL" in this document are to be interpreted as described in RFC 22 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Device Roles . . . . . . . . . . . . . . . . . . . . . . 2 60 1.2. Initiator and Responder Model . . . . . . . . . . . . . . 3 61 1.3. Cautionary Note - on Limitations of Cryptography . . . . 3 62 1.4. Desired Protocol Properties . . . . . . . . . . . . . . . 3 63 1.5. Device Enrolment Phases . . . . . . . . . . . . . . . . . 4 64 1.6. Security Definitions . . . . . . . . . . . . . . . . . . 5 65 1.7. Deployment Scenarios . . . . . . . . . . . . . . . . . . 6 66 2. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 3. Other Related Protocols . . . . . . . . . . . . . . . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Normative references . . . . . . . . . . . . . . . . . . 7 72 6.2. Informative references . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Preliminaries 77 1.1. Device Roles 79 When discussing security operations, it is useful to distinguish 80 various device roles. Here, one should note that a device may assume 81 more than one device role at the same time and that a particular role 82 may be assumed by more than one device. Moreover, the mapping of 83 device roles to devices may change over time (along a device's or 84 network's lifecycle). 86 We distinguish the following roles: 88 1. Client. This device may move in and out of networks (that may be 89 alien to it) and may have little network management functionality 90 on board. Key words: nomadic, promiscuous, constrained. 92 2. Access point. This device may be more tied into a relatively 93 stable infrastructure and may have more support for network 94 management functionality or have reliable access hereto (e.g., 95 via a back-end system). Key words: anchor, semi-stable 96 connectivity, access portal. 98 3. Server. This device provides stable infrastructure and network 99 management support, either intra-domain or inter domain (thereby, 100 offering homogeneous or even heterogeneous functionality). Key 101 words: core function, high availability, human-operator support. 103 4. CA. This device vouches for trust credentials, usually in 104 offline way. Key words: trust anchor. 106 1.2. Initiator and Responder Model 108 All peer-to-peer protocols are role-symmetrical (i.e., the role of 109 initiator/responder roles are interchangeable). Protocols involving 110 a third party assume communications with this third party to take 111 place via the access point (since being the device more tied into 112 infrastructure). 114 1.3. Cautionary Note - on Limitations of Cryptography 116 Cryptographic techniques may provide logical assurances as to a 117 device's identity, where and when communications originated, whom it 118 was intended for, whom this can be read by, etc. 120 Cryptographic techniques do, however, only provide mechanical 121 assurances and can generally not substitute human authorization 122 decision elements (unless the latter are not important, such as with 123 random, ad-hoc networks). 125 1.4. Desired Protocol Properties 127 Security-Related: 129 1. Parties executing a security protocol should be explicitly aware 130 of its security properties 132 2. Compromise of keys or devices should have limited effect on 133 security of other devices or services 135 3. Attacks should not have a serious impact beyond the time 136 interval/space during/in which these take place 138 4. Security protocols should minimize the impact of network outages, 139 denial of service attacks 141 Communication Flows: 143 1. Security protocols should allow to be run locally, without third 144 party involvement, if at all possible 146 2. The number of message exchanges for a joining client device 147 should be reduced 149 3. Message exchanges should be structured so as to allow parallel 150 execution of protocol steps, if possible 152 Computational Cost: 154 1. Security protocols should not impose an undue computational 155 burden, esp. on joining client devices (An exception here may 156 arise, when recovering from an event seriously impacting 157 availability of the network.) 159 Device Capabilities: 161 1. Dependency on an accurate time-keeping mechanism should be 162 reduced 164 2. Computational/time latency trade-offs should be tweaked to 165 benefit those of joining client, if possible 167 3. Dependency on "homogeneous trust models" should be reduced, 168 without jeopardizing security properties 170 4. Dependency on on-board trusted platforms and trusted I/O 171 interfaces should be reduced 173 1.5. Device Enrolment Phases 175 1. Device Authentication. Client A and Access Point B authenticate 176 each other and establish a shared key (so as to ensure on-going 177 authenticated communications). This may involve server KDC as 178 third party. 180 2. Authorization. Access Point B decides on whether/how to 181 authorize device A (if denied, this may result in loss of 182 bandwidth). Authorization decision may be delegated to server 183 KDC or other 3rd-party device. 185 3. Configuration/Parameterization. Access Point B distributes 186 configuration information to Client A, such as 188 * IP address assignment info; 190 * Bandwidth/usage constraints; 192 * Scheduling info (including on re-authentication policy 193 details) 195 This may originate from other network devices, for which it acts 196 as proxy. This step may also include distribution of information 197 from Client A to Access Point B and, more generally, 198 synchronization of information between these two entities. 200 The device enrollment process is depicted in Figure Figure 1, where 201 it is assumed that devices have access to certificates and where 202 entities have access to the root CA key of its communicating parties 203 (initial set-up requirement). Under these assumptions, the 204 authentication step of the device enrollment process does not require 205 online involvement of a third party. 207 {joining node} {neighbor} {server, etc.} 208 +---------+ +---------+ +---------+ 209 | Client | | Access | +--| CA |e.g., certificate 210 | A | | Point B | | +---------+ issuance 211 +---------+ +---------+ | +---------+ 212 | | +--|Authoriz.|e.g., membership 213 |<----Beaconing------| | +---------+ test 214 | | | +---------+ 215 |<--Authentication-->| +--| Routing |e.g., IP address 216 | |<--Authorization-->| +---------+ assignment 217 |<-------------------| | +---------+ 218 | | +--| Gateway |e.g., backbone, 219 |------------------->| | +---------+ cloud 220 | |<--Configuration-->| +---------+ 221 |<-------------------| +--|Bandwidth|e.g., PCE schedule 222 . . . +---------+ 223 . . . 225 Figure 1: Networking Joining, with Only Authorization by Third Party 227 Aggressive scheme: Initiate authorization/configuration processes as 228 soon as (presumed) device identity becomes available (invisible to 229 Client A). Access Point B can deny bandwidth if authorization 230 negative. 232 Note: Communication of configuration info depends on secure channel 233 with Client A. 235 1.6. Security Definitions 237 1. Key Establishment: Protocol whereby a shared secret becomes 238 available to two or more parties for subsequent cryptographic 239 use 241 2. Key Transport: Key establishment technique where one party 242 creates/obtains the secret and securely transfers it to other(s) 244 3. Key Agreement: Key establishment technique where the shared 245 secret is derived based on information contributed by each of 246 the parties involved, ideally so that no party can predetermine 247 this secret value 249 4. Implicit Key Authentication: Assurance as to which specifically 250 identified parties possibly may gain access to a specific key 252 5. Key Confirmation: Assurance that second (possibly unknown) party 253 has possession of a particular key 255 6. Explicit Key Authentication: Combination of implicit key 256 authentication and key confirmation 258 7. Unilateral Key Control: Key establishment protocol whereby one 259 party can influence the shared secret 261 8. Forward Secrecy: Assurance that compromise of long-term keys 262 does not compromise past session keys 264 9. Entity Authentication: Assurance of active involvement of second 265 explicitly identified party in protocol 267 10. Mutual vs. Unilateral: Adjective indicating symmetry, resp. 268 asymmetry, of assurances amongst parties 270 11. Identity Protection: Assurance as to which specifically 271 identified parties may gain access to identity info 273 12. Certificate ? Credential that vouches for authenticity of 274 binding between a public key and other information, including 275 the identity of the owner of the public key in question 277 13. Key Possession? Assurance that a specific (possibly unknown) 278 party has possession of a particular key 280 Esoteric properties: Unknown Key Share Resilience, Session Key 281 Retrieval, Key Compromise Impersonation 283 1.7. Deployment Scenarios 285 Deployment scenarios discussed with industrial control user 286 community: 288 1. Scenario #1: mix-and-match of nodes from different vendors 289 2. Scenario #2: addition of nodes to operational network 291 3. Scenario #3: security audit 293 4. Scenario #4: device repair and replacement (roaming in/out 294 different user sites) 296 5. Scenario #5: network separation (devices joining wrong network) 298 6. Scenario #6: thwarting malicious attacks by (former) insiders 300 7. Scenario #7: thwarting attacks by outsiders via insiders (held at 301 'gunpoint') 303 8. Scenario #8: addition of subsystem ('skid') assembled elsewhere 304 to operational network 306 2. Security Considerations 308 This document is all about security. 310 3. Other Related Protocols 312 4. IANA Considerations 314 5. Acknowledgements 316 Discussions amongst participants in the 6TiSCH security conference 317 calls to-date helped to shape this document. 319 6. References 321 6.1. Normative references 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 327 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 328 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 329 Lossy Networks", RFC 6550, March 2012. 331 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 332 "Neighbor Discovery Optimization for IPv6 over Low-Power 333 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 334 November 2012. 336 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 337 T. Kivinen, "Using Raw Public Keys in Transport Layer 338 Security (TLS) and Datagram Transport Layer Security 339 (DTLS)", RFC 7250, June 2014. 341 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 342 Application Protocol (CoAP)", RFC 7252, June 2014. 344 [I-D.ietf-6tisch-coap] 345 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 346 Interaction using CoAP", draft-ietf-6tisch-coap-00 (work 347 in progress), May 2014. 349 [I-D.ietf-6tisch-architecture] 350 Thubert, P., Watteyne, T., and R. Assimiti, "An 351 Architecture for IPv6 over the TSCH mode of IEEE 352 802.15.4e", draft-ietf-6tisch-architecture-02 (work in 353 progress), June 2014. 355 [I-D.wang-6tisch-6top-sublayer] 356 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 357 Operation Sublayer (6top)", draft-wang-6tisch-6top- 358 sublayer-00 (work in progress), February 2014. 360 [I-D.ietf-6tisch-6top-interface] 361 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 362 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 363 6top-interface-00 (work in progress), March 2014. 365 6.2. Informative references 367 [I-D.garcia-core-security] 368 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 369 R. Struik, "Security Considerations in the IP-based 370 Internet of Things", draft-garcia-core-security-06 (work 371 in progress), September 2013. 373 [I-D.ietf-dice-profile] 374 Hartke, K. and H. Tschofenig, "A DTLS 1.2 Profile for the 375 Internet of Things", draft-ietf-dice-profile-01 (work in 376 progress), May 2014. 378 [I-D.kumar-dice-dtls-relay] 379 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 380 for Constrained Environments", draft-kumar-dice-dtls- 381 relay-01 (work in progress), April 2014. 383 [I-D.thubert-6lowpan-backbone-router] 384 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 385 6lowpan-backbone-router-03 (work in progress), February 386 2013. 388 [IEEE802.15.4-2011] 389 Institute for Electrical and Electronics Engineers, "IEEE 390 802.15.4-2011, IEEE Standard for Local and Metropolitan 391 Area Networks - Part 15.4: Low-Rate Wireless Personal Area 392 Networks (LR-WPANs)", September 2011. 394 [IEEE802.15.4e-2012] 395 Institute for Electrical and Electronics Engineers, "IEEE 396 802.15.4e-2012, IEEE Standard for Local and Metropolitan 397 Area Networks - Part 15.4: Low-Rate Wireless Personal Area 398 Networks (LR-WPANs), Amendment 1: MAC Sublayer", April 399 2012. 401 [Wireless-HART] 402 International Electrotechnical Commission, "IEC 62591, Ed. 403 2.0: Industrial Communication Networks - Wireless 404 Communication Network and Communication Profiles - 405 WirelessHART (Draft)", November 2013. 407 [ISA100.11a] 408 International Electrotechnical Commission, "IEC 62734, Ed. 409 1: Industrial Communication Networks - Wireless 410 Communication Network and Communication Profiles - ISA 411 100.11a (Draft)", May 2013. 413 [ZigBee-IP] 414 ZigBee Alliance, "ZigBee IP Specification (ZigBee Public 415 Document 13-002r00)", February 2013. 417 Author's Address 419 Rene Struik 420 Struik Security Consultancy 422 Email: rstruik.ext@gmail.com