Internet Engineering Task Force (IETF) Phillip Hallam-Baker Internet-Draft Comodo Group Inc. Intended Status: Standards Track October 16, 2014 Expires: April 19, 2015 Software and Configuration Management draft-hallambaker-securecode-00 Abstract Use cases and requirements for secure distribution and management of code are considered. In particular constraints imposed by embedded devices that do not provide affordances for user interaction are considered. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hallam-Baker April 19, 2015 [Page 1] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014 Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Software . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 4 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Device Requirements . . . . . . . . . . . . . . . . . . . 5 4.2. Administration Requirements . . . . . . . . . . . . . . . 5 4.3. Interface Requirements . . . . . . . . . . . . . . . . . 5 5. Technical Requirements . . . . . . . . . . . . . . . . . . . . 5 6. Acnowledgementsts . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Hallam-Baker April 19, 2015 [Page 2] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014 1. Motivation All computing devices operate under control of software. As the applications of computing systems diversify, the management of the software code determining their function becomes an increasingly difficult challenge. The recognition of this problem in the dektop computing environment and the introduction of automatic update mechanisms has played a major role in reducing vulnerabilities on these platforms. But no similar platforms have emerged to support the proliferation of embedded devices currently occuring. While there is a clear need for a software management infrastructure that meets these emerging needs, it is essential that any new security infrastructure meet all the security risks of users and device owners, including the very real possibility that the device vendors themselves might pose the threat. The only difference between a voice activated, network conected toaster oven and a covert surveillance device (aka bug) is the software it runs. The possibility that a device might change its function through an unsolicited software is just as important a security concern as the possibility that code might contain zero day vulnerabilities. Existing systems, including those deployed to update open source platforms have been developed to serve the proprietary interest of the software provider to update their code. The disregard for the concerns of the user/owner is made clear by a user interaction where the only choice is to update now or to be reminded in an hour's time. Rather unusually, devices sold to the consumer market tend to be considerably worse than those sold to enterprises. Enterprises understand that automatic software updates present security risks as well as benefits. A software update mechanism that is outside their direct control may invalidate previous Quality Assurance processes causing a system to fail. Since automatic update mechanisms rarely receive attention in product reviews, the needs of consumers have been treated with conspicuous contempt. In the majority of cases, no attempt is made to minimize the inconvenience to the user. The device determines that an update is required and refuses to perform its intended function until the user approves installation of the update, the update is downloaded and installed. Approaches such as this are at best discourteous but can pose a serious safety risk if they interfere with the functioning of critical systems. While the manufacturer of a defibrilating device is likely to understand that it must work immediately every time it is used, most systems become critical because people rely on them to Hallam-Baker April 19, 2015 [Page 3] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014 function rather than this being an intrinsic aspect of their purpose. 2. Definitions 2.1. Software The term 'software' is used to describe any content that might affect the operation of a device that is not provided by its administrator and/or user(s). Rationale: What is important from the security point of view is that the content might affect the operation of the machine rather than the classification of the content as 'code' or 'data'. A data driven code system need not be Turing complete for it present a user-access or root-access level vulnerability. Note that for the purposes of software management, there is no useful distinction between 'software' and 'firmware'. Either may affect the operation of the machine. 2.2. Configuration The term 'configuration' is used to describe any content that might affect the operation of a device that is provided by its administrator and/or user(s). Rationale: Anything that is not software that might affect the operation of the device is a security concern and thus should be considered in the device management infrastructure. 3. Principles * The integrity of the system software and configuration should always be assured. * The operation of a system should be controlled by the owner. No modifications should be made to the operation of a device without express permission from the owner or their delegate. * If the owner's ability to modify either software or configuration is limited in any fashion, these constrains should be clearly declared. * The software and configuration of a system should always be known with certainty. * Changes to software and/or configuration should be auditable and reversible. Hallam-Baker April 19, 2015 [Page 4] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014 Note that the requirement for express permission does not entail specific user interaction on the part of the owner. Since most owners have neither the means nor the inclination to decide whether an update should be performed, the ability to delegate decision making powers to the software provider or a third party is highly desirable provided that such delegation is revokable and the exercise of the delegated powers can be audited. 4. Requirements Consumer software update systems are generally implemented as a feature of the system under management while enterprise software management systems typically observe a separation between the administration system and the systems under management. 4.1. Device Requirements * Report the software packages installed on a system. * Transfer a software package to a system. * Install a software package on a system. * Delete a software package from a system. * Change the software package version to be executed on a system at next restart. * Change the software package version to be executed now. * Schedule a restart. 4.2. Administration Requirements * Determine what vulnerabilities have been reported for a software package. * Verify the provenance of a software package. 4.3. Interface Requirements * Bind a device to an administration source. 5. Technical Requirements 6. Acnowledgementsts This document was written in response to discussion on the IETF list begun by Jim Gettys. Hallam-Baker April 19, 2015 [Page 5] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014 Author's Address Phillip Hallam-Baker Comodo Group Inc. philliph@comodo.com Hallam-Baker April 19, 2015 [Page 6]