idnits 2.17.1 draft-struik-6tisch-security-architecture-elements-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 12 instances of too long lines in the document, the longest one being 4 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 297, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-02 Summary: 2 errors (**), 0 flaws (~~), 4 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 Y. Ohba 5 Expires: April 30, 2015 Toshiba 6 S. Das 7 ACS 8 October 27, 2014 10 6TiSCH Security Architectural Elements, Desired Protocol Properties, and 11 Framework 12 draft-struik-6tisch-security-architecture-elements-01 14 Abstract 16 This document describes 6TiSCH security architectural elements with 17 high level requirements and the security framework that are relevant 18 for the design of the 6TiSCH security solution. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 30, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Security Architecture Elements . . . . . . . . . . . . . . . 2 55 1.1. Device Types and Roles . . . . . . . . . . . . . . . . . 2 56 1.2. Device Enrollment Phases . . . . . . . . . . . . . . . . 3 57 1.3. Desired Protocol Properties . . . . . . . . . . . . . . . 3 58 2. Security Framework . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Single-Stage Authentication Framework . . . . . . . . . . 4 60 2.2. Two-Stage Authentication Framework . . . . . . . . . . . 5 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Security Architecture Elements 69 1.1. Device Types and Roles 71 There are two types of devices (or nodes) that are involved in the 72 6TiSCH security architecture: end devices that intend to join the LLN 73 (commonly known as joining nodes) and network devices that help the 74 joining node to be authenticated and authorized by the network. From 75 a security operations perspective, each device has a distinct role in 76 the network. An end device has normally a client role, while the 77 network device can be a proxy or assume a server role. A proxy is an 78 intermediate node that helps the end device to establish a 79 communication with the server. An end device may move in and out of 80 networks (that may be alien to it) and may have little network 81 management functionality on board. However, it usually does have the 82 right credential required for initializing the network joining 83 process. A proxy is an intermediary node that that may be more tied 84 into a relatively stable infrastructure and may have more support for 85 network management functionality and generally has reliable access to 86 back-end systems of the network. A server provides stable, highly 87 available infrastructure and network management support and is 88 capable of authenticating and authorizing a joining node. 90 It is important to note that a network node may assume multiple roles 91 at the same time and that a particular role may be assumed by 92 multiple network nodes. Furthermoe, the roles of a network node may 93 change over time and can be dynamic in nature along a node or a 94 network's lifecycle. 96 1.2. Device Enrollment Phases 98 Device Authentication: The joining node and network node authenticate 99 each other and establish a shared key, so as to ensure on-going 100 authenticated communications. This may involve a server as a third 101 party. 103 Authorization: The network node decides on whether/how to authorize a 104 joining node (if denied, this may result in loss of bandwidth). 105 Authorization decisions may involve other nodes in the network. 107 Configuration/Parameterization: The network node distributes 108 configuration information to the joined node, such as scheduling 109 information, IP address assignment information, and network policies. 110 This may originate from other network devices, for which it acts as 111 proxy. This step may also include distribution of information from 112 the joining node to the network node and, more generally, 113 synchronization of information between these entities. 115 1.3. Desired Protocol Properties 117 Security-Related: 119 1. Parties executing a security protocol should be explicitly aware 120 of its security properties; 122 2. Compromise of keys or devices should have limited effect on 123 security of other devices or services; 125 3. Attacks should not have a serious impact beyond the time 126 interval/space during/in which these take place; 128 4. Security protocols should minimize the impact of network outages, 129 denial of service attacks. 131 Communication Flows: 133 1. Security protocols should allow to be run locally, without third 134 party involvement, wherever possibl; 136 2. The number of message exchanges for a joining device should be 137 reduced; 139 3. Message exchanges should be structured so as to allow parallel 140 execution of protocol steps, wherever possible. 142 Computational Cost: 144 1. Security protocols should not impose an undue computational 145 burden, especially on joining devices (An exception here may 146 arise, when recovering from an event seriously impacting 147 availability of the network.) 149 Device Capabilities: 151 1. Dependency on an accurate time-keeping mechanism should be 152 reduced; 154 2. Computational/time latency trade-offs should be tweaked to 155 benefit those of joining node, wherever possible; 157 3. Dependency on "homogeneous trust models" should be reduced, 158 without jeopardizing the security properties; 160 4. Dependency on on-board trusted platforms and trusted I/O 161 interfaces should be reduced. 163 2. Security Framework 165 2.1. Single-Stage Authentication Framework 167 In the single-stage authentication and authorization framework, 168 depicted in Figure 1, it is assumed that devices have access to 169 certificates and that entities have access to the root CA certificate 170 of their communicating parties (initial set-up requirement). Under 171 these assumptions, the authentication step of the device enrollment 172 process does not require online involvement of a third party. 173 Authentication is performed between the joining node and the proxy 174 using their certificates. Upon successful authentication, link-layer 175 keys are established between the client and the proxy. The proxy 176 will deny bandwidth if authorization is not successful. After 177 successful authentication and authorization, configuration 178 information is exchanged. 180 When a device rejoins the network in the same authorization domain, 181 the authorization step could be omitted if the server distributes the 182 authorization state for the device to the proxys when the device 183 initially joined the network. However, this generally still requires 184 the exchange of updated configuration information, e.g., related to 185 time schedules and bandwidth allocation. 187 {joining node} {neighbor} {server, etc.} 188 +---------+ +---------+ +---------+ 189 | Node | | Proxy | +--| CA |e.g., certificate 190 | A | | B | | +---------+ issuance 191 +---------+ +---------+ | +---------+ 192 | | +--|Authoriz.|e.g., membership 193 |<----Beaconing------| | +---------+ test 194 | | | +---------+ 195 |<--Authentication-->| +--| Routing |e.g., IP address 196 | |<--Authorization-->| +---------+ assignment 197 |<-------------------| | +---------+ 198 | | +--| Gateway |e.g., backbone, 199 |------------------->| | +---------+ cloud 200 | |<--Configuration-->| +---------+ 201 |<-------------------| +--|Bandwidth|e.g., PCE 202 +---------+ schedule 203 . . . 204 . . . 206 Figure 1: Single-stage authentication/authorization 208 2.2. Two-Stage Authentication Framework 210 In the two-stage authentication and authorization framework, depicted 211 in Figure 2, a joining node performs two authentication and 212 authorization steps. The first step, called Phase-1 authentication, 213 is performed between the joining node and the server via a proxy. 214 Phase-1 authentication and authorization uses deployment-specific 215 enrollment credentials and results in issuance of a certificate by 216 the CA to the joining node. Here, the node's certificate and root CA 217 certificates of its communicating parties are distributed from the 218 server to the client. 220 The second step, called Phase-2 authentication, follows the 221 successful completion of Phase-1 authentication and authorization. 222 Phase-2 authentication is performed between the joining node and the 223 proxy using their certificates. Upon successful authentication, 224 link-layer keys are established between the joining node and the 225 proxy. The proxy will deny bandwidth if Phase-2 authorization is not 226 successful. After successful authentication and authorization, 227 configuration information is exchanged. 229 Once a joining node obtains a certificate for Phase-2 authentication, 230 no additional Phase-1 authentication and authorization is needed, 231 i.e., only Phase-2 authentication and the configuration are required 232 for rejoining the network via a proxy under the same authorization 233 domain. This reduces to the single-stage authentication framework 234 discussed in the previous section. 236 {joining node} {neighbor} {server, etc.} 237 +---------+ +---------+ +---------+ 238 | Node | | Proxy | +--| CA |e.g., certificate 239 | A | | B | | +---------+ issuance 240 +---------+ +---------+ | +---------+ 241 | | +--|Authoriz.|e.g., membership 242 |<----Beaconing--------| | +---------+ test 243 | | | +---------+ 244 |<-Ph1 Authentication & Authorization->+--| Routing |e.g., IP address 245 | | | +---------+ assignment 246 |<-Ph2 Authentication->| | +---------+ 247 | | +--| Gateway |e.g., backbone, 248 |--------------------->| | +---------+ cloud 249 | |<-- Config. -->| +---------+ 250 |<---------------------| +--|Bandwidth|e.g., PCE schedule 251 . . . +---------+ 252 . . . 254 Figure 2: Two-stage authentication/authorization 256 3. Security Considerations 258 In this section, security issues that can potentially impact the 259 operation of IEEE 802.15.4e TSCH MAC are described. 261 In TSCH MAC, time synchronization and channel hopping information are 262 advertised in Enhanced Beacon (EB) frames 263 [I-D.ietf-6tisch-terminology]. The advertised information is used by 264 mesh nodes to determine the timeslots available for transmission and 265 reception of MAC frames. A rogue node can inject forged EB frames 266 and can cause replay and DoS attacks to TSCH MAC operation. To 267 mitigate such attacks, all EB frames MUST be integrity protected. 268 While it is possible to use a pre-installed static key for protecting 269 EB frames to every node, the static key becomes vulnerable when the 270 associated MAC frame counter continues to be used after the frame 271 counter wraps. Therefore, the 6TiSCH solution MUST provide a 272 mechanism by which mesh nodes can use the available time slots to run 273 authentication protocols and provide integrity protection to EB 274 frames. 276 For use cases where certificates are used for authentication, pre- 277 provisioning of absolute time to devices from a trustable time source 278 using an out-of-band (OOB) mechanism is a general requirement. 280 Accuracy of time depends on the OOB mechanism, including use of the 281 time hard-coded into the installed firmware. The less time accuracy 282 is, the more attack opportunities during Phase-1. In addition, use 283 of CRL is another requirement for authentication employing 284 certificates to avoid an attack that can happen by a compromised 285 server or CA certificate. 287 4. IANA Considerations 289 There is no IANA action required for this document. 291 5. Acknowledgments 293 TBD. 295 6. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [I-D.ietf-6tisch-terminology] 301 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 302 "Terminology in IPv6 over the TSCH mode of IEEE 303 802.15.4e", draft-ietf-6tisch-terminology-02 (work in 304 progress), July 2014. 306 Authors' Addresses 308 Rene Struik 309 Struik Security Consultancy 311 Email: rstruik.ext@gmail.com 313 Yoshihiro Ohba 314 Toshiba Corporate Research and Development Center 315 1 Komukai-Toshiba-cho 316 Saiwai-ku, Kawasaki, Kanagawa 212-8582 317 Japan 319 Phone: +81 44 549 2127 320 Email: yoshihiro.ohba@toshiba.co.jp 321 Subir Das 322 Applied Communication Sciences 323 1 Telcordia Drive 324 Piscataway, NJ 08854 325 USA 327 Email: sdas@appcomsci.com