idnits 2.17.1 draft-hallambaker-securecode-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 a Security Considerations section. ** 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 (October 16, 2014) is 3480 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track October 16, 2014 4 Expires: April 19, 2015 6 Software and Configuration Management 7 draft-hallambaker-securecode-00 9 Abstract 11 Use cases and requirements for secure distribution and management of 12 code are considered. In particular constraints imposed by embedded 13 devices that do not provide affordances for user interaction are 14 considered. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 Copyright Notice 33 Copyright (c) 2014 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1. Software . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4.1. Device Requirements . . . . . . . . . . . . . . . . . . . 5 55 4.2. Administration Requirements . . . . . . . . . . . . . . . 5 56 4.3. Interface Requirements . . . . . . . . . . . . . . . . . 5 57 5. Technical Requirements . . . . . . . . . . . . . . . . . . . . 5 58 6. Acnowledgementsts . . . . . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Motivation 63 All computing devices operate under control of software. As the 64 applications of computing systems diversify, the management of the 65 software code determining their function becomes an increasingly 66 difficult challenge. 68 The recognition of this problem in the dektop computing environment 69 and the introduction of automatic update mechanisms has played a 70 major role in reducing vulnerabilities on these platforms. But no 71 similar platforms have emerged to support the proliferation of 72 embedded devices currently occuring. 74 While there is a clear need for a software management infrastructure 75 that meets these emerging needs, it is essential that any new 76 security infrastructure meet all the security risks of users and 77 device owners, including the very real possibility that the device 78 vendors themselves might pose the threat. The only difference between 79 a voice activated, network conected toaster oven and a covert 80 surveillance device (aka bug) is the software it runs. 82 The possibility that a device might change its function through an 83 unsolicited software is just as important a security concern as the 84 possibility that code might contain zero day vulnerabilities. 86 Existing systems, including those deployed to update open source 87 platforms have been developed to serve the proprietary interest of 88 the software provider to update their code. The disregard for the 89 concerns of the user/owner is made clear by a user interaction where 90 the only choice is to update now or to be reminded in an hour's time. 92 Rather unusually, devices sold to the consumer market tend to be 93 considerably worse than those sold to enterprises. Enterprises 94 understand that automatic software updates present security risks as 95 well as benefits. A software update mechanism that is outside their 96 direct control may invalidate previous Quality Assurance processes 97 causing a system to fail. 99 Since automatic update mechanisms rarely receive attention in product 100 reviews, the needs of consumers have been treated with conspicuous 101 contempt. In the majority of cases, no attempt is made to minimize 102 the inconvenience to the user. The device determines that an update 103 is required and refuses to perform its intended function until the 104 user approves installation of the update, the update is downloaded 105 and installed. 107 Approaches such as this are at best discourteous but can pose a 108 serious safety risk if they interfere with the functioning of 109 critical systems. While the manufacturer of a defibrilating device is 110 likely to understand that it must work immediately every time it is 111 used, most systems become critical because people rely on them to 112 function rather than this being an intrinsic aspect of their purpose. 114 2. Definitions 116 2.1. Software 118 The term 'software' is used to describe any content that might affect 119 the operation of a device that is not provided by its administrator 120 and/or user(s). 122 Rationale: What is important from the security point of view is that 123 the content might affect the operation of the machine rather than the 124 classification of the content as 'code' or 'data'. A data driven code 125 system need not be Turing complete for it present a user-access or 126 root-access level vulnerability. 128 Note that for the purposes of software management, there is no useful 129 distinction between 'software' and 'firmware'. Either may affect the 130 operation of the machine. 132 2.2. Configuration 134 The term 'configuration' is used to describe any content that might 135 affect the operation of a device that is provided by its 136 administrator and/or user(s). 138 Rationale: Anything that is not software that might affect the 139 operation of the device is a security concern and thus should be 140 considered in the device management infrastructure. 142 3. Principles 144 * The integrity of the system software and configuration should 145 always be assured. 147 * The operation of a system should be controlled by the owner. No 148 modifications should be made to the operation of a device 149 without express permission from the owner or their delegate. 151 * If the owner's ability to modify either software or 152 configuration is limited in any fashion, these constrains 153 should be clearly declared. 155 * The software and configuration of a system should always be 156 known with certainty. 158 * Changes to software and/or configuration should be auditable 159 and reversible. 161 Note that the requirement for express permission does not entail 162 specific user interaction on the part of the owner. Since most owners 163 have neither the means nor the inclination to decide whether an 164 update should be performed, the ability to delegate decision making 165 powers to the software provider or a third party is highly desirable 166 provided that such delegation is revokable and the exercise of the 167 delegated powers can be audited. 169 4. Requirements 171 Consumer software update systems are generally implemented as a 172 feature of the system under management while enterprise software 173 management systems typically observe a separation between the 174 administration system and the systems under management. 176 4.1. Device Requirements 178 * Report the software packages installed on a system. 180 * Transfer a software package to a system. 182 * Install a software package on a system. 184 * Delete a software package from a system. 186 * Change the software package version to be executed on a system 187 at next restart. 189 * Change the software package version to be executed now. 191 * Schedule a restart. 193 4.2. Administration Requirements 195 * Determine what vulnerabilities have been reported for a 196 software package. 198 * Verify the provenance of a software package. 200 4.3. Interface Requirements 202 * Bind a device to an administration source. 204 5. Technical Requirements 206 6. Acnowledgementsts 208 This document was written in response to discussion on the IETF list 209 begun by Jim Gettys. 211 Author's Address 213 Phillip Hallam-Baker 214 Comodo Group Inc. 216 philliph@comodo.com