idnits 2.17.1 draft-richardson-smartobject-security-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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2012) is 4460 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 212, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-phinney-roll-rpl-industrial-applicability-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Smart Object Security Workshop M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational February 7, 2012 5 Expires: August 10, 2012 7 Challenges in Smart Object Security: too many layers, not enough ram 8 draft-richardson-smartobject-security-00 10 Abstract 12 This is a position paper for the pre-IETF83 Workshop on Smart Object 13 Security. The author contends that layer-2 security solutions are 14 not only in-adequate, but may in fact be harmful when deployed into 15 smart object systems. While layer-2 security services may be 16 valuable, they must be channel bound up to the layer-7 application 17 layer. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 10, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. What we need . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 4.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 The ROLL RPL specification provides an optional layer-3 security 65 mechanism. The WG did not focus very much on making this security 66 system useable, as most WG participants assumed that layer-2 would 67 provide all the security that most deployments would want. 69 While the ZigBee 2007 is provides a stack up to the application, and 70 clearly articulates the role of the application in the security 71 system, if ROLL RPL applicability statements specify Zigbee at all 72 (XXX), from Zigbee's point of view the "application" is IPv6. The 73 security provided by Zigbee 2007 does not get translated up to the 74 IPv6 application, and certainly is not leveraged for end-to-end 75 security. 77 Other specifications, including 6LowPAN (mesh-over) and ISA100 use a 78 network key essentially identical to the 802.11 WEP. While many of 79 these specifications propose to upgrade their mechanisms to include 80 WPA-like usage of EAP, this does not solve the fundamental security 81 problem of *authorization*. Except for auditing purposes, the 82 network does not care who the nodes are, but rather, are they 83 authorized to perform a particular function. In the context of RPL, 84 one of these key functions is routing of packets. 86 A good example of the lack of security feature is that it is 87 impossible in RPL to create a network where some nodes are authorized 88 to route packets, while other nodes are not. While the specification 89 supports this when doing layer-3 security, it only supports it for 90 asymmetric security methods, widely regarded as too expensive for 91 small devices. If the security is provided by a layer-2, then even 92 if asymmetric methods are used in that layer, they are not available 93 to the RPL (or higher) layers. 95 2. What we need 97 What we need is a security service implemented in layer-2 or layer-3, 98 which not only provides for the privacy and integrity that is 99 typically sought, but also can be leveraged by upper layers 100 (including the layer-3 routing layer), to make authorization 101 decisions. 103 Layer 2 alliances have created detailed and complex security 104 specifications for wireless connectivity of smart objects. The 105 requirements seems to have driven by existing early adopters of 106 building and industrial automation. For many of the participants, 107 security has become magic pixie dust provided by the vendor of the 108 layer 2 MAC/radio. 110 I had believed that layer 3 security was more appropriate and easier 111 to deploy/update. While requiring possibly more software code space, 112 it might have a lower transitor count as flash is sometimes cheaper 113 than complex logic in a MAC. But, I wondered who would need such 114 flexibility among current industrial and smartgrid users of ROLL? 115 Maybe it just my desire to do ubiquitous l3 networking with strangers 116 on the bus, and I should shut up and believe that l2 security is 117 enough. 119 Then the ROLL WG came to applicability statements, and it has obvious 120 to me that people installing industrial equipement have much more 121 complex requirements than I could even imagine on the bus. On the 122 bus, I most trust everyone exactly the same: if they get my 123 cryptographically signed packets to my intended destination, then I'm 124 happy. I have really only one level of authorization: I either let 125 you route my packets, or I do not. If I do not trust you to route, I 126 might still trust you to have a cached copy of some data I want, and 127 I have a way to authenticate the data itself. 129 The home automation users of ROLL was where I figured the most 130 complexity would occur, and this relates mostly to how guests and 131 children in the home will interact with the home system(s). While 132 the lighting and appliance control network in the home looks very 133 much like an commercial building system, how the occupants of the 134 home interact with this system is not well defined as yet. It is 135 likely that initially all interaction will be via hard controls 136 ("light switches"), or via a gateway system that not only connected 137 the 802.11 and 802.15.4 networks, but also provided an authentication 138 and authorization system between the two networks. The ROLL provided 139 security need concern itself only with whether or not a device was 140 part of the home network or not, something that layer-2 security can 141 do. 143 However, smart phones and personal area networks will begin to get 144 802.15.4 interfaces, and in some cases home automation is escrewing 145 802.15.4, claiming that 802.11 is now so cheap (power and bill-of- 146 material) that it makes no sense to assume/require a gateway device. 147 This is where, I thought, the multi-level authorization security 148 would be required, and this would be subject to much innovation, with 149 a number of home automation systems proving inadequate and being 150 upgraded or replaced over time. 152 I thought that only when we have house guests (consider a teenage 153 child to be an extended stay house guest) that we would run into 154 troubles: we definitely want to authorize our guests to do many 155 things in our homes, but there are many things we do not want them to 156 do. 158 What I did I not expect was that industrial users would in fact 159 require a multi-level authorization system, and have rekeying and 160 trust issues more complex than that of the home. It was once 161 explained that the militaries aren't into authorization: they care 162 about authentication and auditing. A soldier must always have the 163 ability to exceed their authority, because sometimes it's the right 164 thing to do, and if they did the wrong thing, they have the court 165 martial to solve this problem. 167 The court martial is not a solution for the industrial ROLL user. 168 The various modes of operation described in 169 [I-D.phinney-roll-rpl-industrial-applicability] require several 170 levels of trust. While layer-2 security has a place, it seems that 171 the installers of the devices (who would have to configure the 172 layer-2 security) are not to be trusted in the long term, and 173 therefore some way to change layer-2 keying material needs to be 174 standardized. 176 If during any unplanned (i.e. emergency) situation new equipment will 177 be brought into the plant to aid in recovery, that this equipment 178 either will need to be configured (by regular plant personal) with 179 the right security, or it will be necessary to either turn off or 180 revert security to some other more minimal configuration, such that 181 the equipment can be used. 183 It appears that not only is LAYER 2 security is not only inadequate, 184 but may be actually too difficult to configure, simply because 185 devices can not configure once installed. I am concerned that 186 without a better answer, every building and plant will -- like most 187 BlueTooth heads -- have PIN 0000! 189 We need something more sophisticated: sophisticated enough to be 190 simple. 192 3. Security Considerations 194 This document does not propose any changes to existing or new 195 systems, but rather details limitations of a current security model 197 4. References 199 4.1. Normative References 201 [I-D.phinney-roll-rpl-industrial-applicability] 202 Phinney, T., Thubert, P., and R. Assimiti, "RPL 203 applicability in industrial networks", 204 draft-phinney-roll-rpl-industrial-applicability-00 (work 205 in progress), October 2011. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 4.2. Informative References 212 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 213 June 1999. 215 Appendix A. Additional Stuff 217 This becomes an Appendix. 219 Author's Address 221 Michael C. Richardson 222 Sandelman Software Works 223 470 Dawson Avenue 224 Ottawa, ON K1Z 5V7 225 CA 227 Email: mcr@sandelman.ca 228 URI: http://www.sandelman.ca/mcr/