DICE B. Greevenbosch Internet-Draft Huawei Technologies Intended status: Informational July 05, 2013 Expires: January 06, 2014 Use cases and requirements for authentication, authorisation and revocation in the Internet of Things draft-greevenbosch-dice-authent-author-revoc-00 Abstract This draft describes use cases and associated requirements for authentication, authorisation and revocation within the Internet of Things. Note Discussion and suggestions for improvement are requested, and should be sent to dtls-iot@ietf.org. 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." This Internet-Draft will expire on January 06, 2014. Copyright Notice Copyright (c) 2013 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 Greevenbosch Expires January 06, 2014 [Page 1] Internet-Draft Authentication, authorisation, revocation July 2013 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Discovered compromised device . . . . . . . . . . . . . . 3 3.2. Unauthorised device . . . . . . . . . . . . . . . . . . . 3 3.3. Revocation of unsafe devices . . . . . . . . . . . . . . 4 3.4. Man-in-the-middle . . . . . . . . . . . . . . . . . . . . 4 3.5. Illegal smart-meters . . . . . . . . . . . . . . . . . . 4 3.6. Maintaining and extending a network of sensors and actuators . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Vulnerability discovery in actuators in a chemical plant 5 3.8. Revocation of a non-compromised device . . . . . . . . . 6 3.9. Mixing nodes from different vendors . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Certificate Authority . . . . . . . . . . . . . . . . . . 7 5.2. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Time of revocation . . . . . . . . . . . . . . . . . . . 8 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction This draft describes use cases and requirements for secure authentication, authorisation and revocation in the Internet of Things. The draft has the following parts: o The draft starts with several use cases. Greevenbosch Expires January 06, 2014 [Page 2] Internet-Draft Authentication, authorisation, revocation July 2013 o A section with requirements related to the use-cases follows. o Discussion of the various security trade-offs that need to be made can be found in Section 5. o A table with some common attacks and associated protection, a conclusion and a recommendation is given in the "Conclusions" section. The draft illustrates the importance of these subjects, and aims at making sure these subjects are given proper attention in DICE. 3. Use cases 3.1. Discovered compromised device Company A has a certain type of actuators installed throughout its building. On a certain time, some of these actuators start behaving funny. It turns out that some hackers have been able to access the sensors, and drive them as they wish. Company A can't de-install the actuators immediately, after all, they are installed everywhere in the building. Instead Company A has the actuators revoked, and then can replace them on a less hasty schedule. 3.2. Unauthorised device Company B produces sensor devices. These devices have known security issues, and therefore fail the certification requirements. Company C is oblivious of this fact, and since it needs this kind of sensors to monitor its industrial process, it buys some to test. During installation of the sensors into Company C's monitoring network, the credentials of the sensors are verified. The authentication fails, and the installation of the sensors is aborted. The installation engineers are informed about the reason of failure. The sensor devices should never have been sold, as usage leads to potential danger. Fortunately the authentication mechanism revealed that the sensors are not to be used. Greevenbosch Expires January 06, 2014 [Page 3] Internet-Draft Authentication, authorisation, revocation July 2013 3.3. Revocation of unsafe devices Company D produces switches, that turn on or off connected peripherals. After a while, Company D finds out a problem with a particular series of its on/off switches. It turns out that a certain vulnerability allows hackers to drive the switches. For legal and ethnic reasons, as Company D cannot guarantee the safety of its switches anymore, it has to to revoke the related series. In addition, Company D publishes its reasons for the revocation of the series and offers free replacement of the affected switches. In this example, there is not yet any adversary involved. But since Company D found the vulnerability before havoc was wreaked, it was able to revoke the affected switches on time. This eliminated a lot of potential trouble. 3.4. Man-in-the-middle A classic attack. In this scenario, we assume there is no secure authentication/authorisation mechanism. Alice has bought a device that she wants to connect to her network. When Alice starts installing, the message that delivers the key from the switch to Alice's gateway is intercepted by Mallory's intercepter. Mallory replaces Alice's public key with his own public key A, and registers for Alice instead. In addition, Mallory impersonates his intercepter to be the gateway by sending Alice his public key B (which may or may not be equal to A). From now on, Mallory can read and modify any communication between Alice's device and her gateway. Mallory is able to do this because neither the device of the gateway have means to authenticate the other party. In addition, there is no mechanism saying that Mallory is not authorised to do the things he wants to do. 3.5. Illegal smart-meters An electricity company depends on smart-meters to measure energy usage of the households it servers. The gathered information is used for several purposes, billing being one of them. Greevenbosch Expires January 06, 2014 [Page 4] Internet-Draft Authentication, authorisation, revocation July 2013 On the black market, there appear illegal smart-meters that only report 75% of the actual electricity usage. These smart-meters are based on a clone of a valid public key. Once the electricity company discovers this, it revokes the associated public key, thereby ensuring that the illegal meters cannot be installed anymore. 3.6. Maintaining and extending a network of sensors and actuators An agricultural company uses an IP network to ensure an optimal climate for the vegetables they grow in their green houses. Sensors do measurements about e.g. humidity and sunlight, whereas actuators can drive artificial rain and supporting light. A central controller is responsible for processing the sensor readings and driving the actuators accordingly. Sometimes, a sensor or actuator needs replacement as part of the normal maintenance cycle. This is a routine task for the associated engineer, and involves simply disconnecting the old apparatus and connecting a new one. The rest of the installation to the network happens automatically. As the agricultural company is doing good business, it decides to expand. It buys another piece of land, and modernises the green house that was already built on the land. The modernisation includes installing new sensors and actuators, which are seamlessly integrated into the already existent network, such that they can work with the central controller too. The use case illustrates the need to be able to automatically install and update network nodes in an existing network. It is also important to note, that installation of the network nodes includes proper authentication and authorisation. After all, the agricultural company does not want outsiders to be able to influence the climate in the green houses, for example by driving the actuators or modifying the sensor readings. 3.7. Vulnerability discovery in actuators in a chemical plant Company E maintains a chemical plant. The plant deploys sensors for the several properties of the substance being produced, and actuators that start certain processes when the substance is ready for the next step. A vulnerability in certain of the actuators is discovered; it would allow unauthorised third parties to take over the actuators and start processes at their will. Greevenbosch Expires January 06, 2014 [Page 5] Internet-Draft Authentication, authorisation, revocation July 2013 After the discovery of the vulnerability, company E pro-actively de- activates the actuators and revokes their keys. It then makes sure the vulnerability is resolved as quickly as possible, such that normal production can resume. 3.8. Revocation of a non-compromised device Jack worked at the IT department of company E. However, due to a conflict with the company, Jack has been fired. When leaving, he smuggled out some tokens used to control several of the company's peripherals. When the company realises it misses the tokens, it revokes them to ensure they cannot be used to control the peripherals anymore. Jack fails to wreak havoc as his revenge, and neither can he sell the tokens to other adversaries. 3.9. Mixing nodes from different vendors A weather analysis and forecast agency needs global coverage for collection of temperature and air-pressure data. It has contracts with several local authorities and companies for the placement of their sensors. For both logistic and economic reasons, the weather agency does not want to rely on one particular type of sensor from a single vendor. Instead, it wants to allow different sensors from different vendors, as long as these sensors meet certain criteria concerning precision, response time and reliability. To ensure the criteria are met, the weather agency performs several tests with new candidate sensors. When the sensors pass the tests, the agency allows their usage in its network. When the sensors fail the tests, the agency is ensured that they cannot be used for collecting data, lest the quality of the agency's analysis and forecast suffer from data of bad quality. In this use case, the vendor pro-actively controls which sensor types can be used in their network. It uses an authentication and authorisation mechanism to automatically ensure that only those types it has approved can be installed. The use case illustrates the need for interoperability in authentication between nodes manifactured by different vendors, as well as the need to exclude nodes that are not authorised to join the network. Greevenbosch Expires January 06, 2014 [Page 6] Internet-Draft Authentication, authorisation, revocation July 2013 4. Requirements This section lists requirements for authentication, authorisation and revocation: 1. It SHALL be possible for a receiver to determine whether a key has been revoked. 2. It SHALL be possible to verify the binding between the key and the entity associated with it. 3. It SHALL be possible to verify whether an entity is authorised to establish the connection. 4. There SHALL be a mechanism that allows revocation of previously granted authorisation. 5. It SHALL be possible to perform authentication, authorisation and revocation verification fully automatically. 6. The verification technology MUST NOT require much complexity on constrained entities. 7. The verification mechanism SHALL be scalable, allowing potentially millions of entities to verify authentication and authorisation. 8. It SHOULD be possible to specify an expiry date for keys and/or authorisation. 9. It SHALL NOT be possible for an unauthorised third party to establish a cryptographic relationship. 10. It SHALL be possible to revoke compromised keys. 11. Revocation SHALL NOT require physically unplugging the device. 12. There SHALL be protection against an unauthorised third party authorising and revoking keys and entities. 5. Discussion In this section, we discuss the various trade-offs that need to be made, and implications they may have. 5.1. Certificate Authority Greevenbosch Expires January 06, 2014 [Page 7] Internet-Draft Authentication, authorisation, revocation July 2013 Much of a traditional Public Key Infrastructure depends on a certificate authority. The certificate authority (CA) signs the certificate of the device, or an intermediate certificate that signs the certificate of the device. This creates islands of trust, in which the CA has the power to revoke any key on its island. Interoperability between devices of different CAs may still be possible, depending on which CAs the entities trust apart from their own CA. 5.2. Expiry X.509 certificates [X.509] contain an expiry date. This means that the certificates automatically become invalid after a time has passed. Should the device's lifetime be longer than the validity period of the certificate, then the certificate has to be updated. The expiry date has the advantage that there is no need to keep track of revoked certificates infinitely. After the certificate's expiration, the revocation status can be forgotten. However a major draw-back is that a mechanism is needed to update expired certificates, provided that the entities holding them should continue to be used. 5.3. Time of revocation Authentication and revocation are normally checked when two entities meet each other for the first time. But how about entities that are to be revoked later? The dealings with this highly depends on the security requirements of the employed system. For example, home light-switches may have less stringent security requirements than actuators in a chemical plant. In the former, a revocation mechanism for deployed devices may not be needed, whereas in the latter it is essential. 6. Conclusions The following table gives an overview of various well-known attacks and applicable protection: +---------------------+----------------+---------------+------------+ | Attack | Authentication | Authorisation | Revocation | +---------------------+----------------+---------------+------------+ | Man-in-the-middle | Y | Y | Y | | | | | | | Unauthorised access | Y | Y | Y | | | | | | Greevenbosch Expires January 06, 2014 [Page 8] Internet-Draft Authentication, authorisation, revocation July 2013 | Key compromise | | | Y | +---------------------+----------------+---------------+------------+ Notice that a key compromise can allow both a man-in-the-middle attack and unauthorised access, hence the revocation requirement for all three attacks. The author of this draft believes that the given use-cases and requirements justify proper attention in DICE, and recommends including the following text into the charter: "The DICE working group will carefully consider the aspects of authentication, authorisation and revocation, and define or re-use related mechanisms where appropriate." 7. Security considerations This whole draft concerns security considerations. We refer to the rest of the draft for the complete picture. 8. IANA considerations No IANA requests are required for this document. 9. Acknowledgements Thanks to Rene Struik and Kepeng Li for their valuable feedback. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [X.509] , "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. ", ITU-T Recommendation X.509, ISO/IEC 9594-8:2005, 2005. Greevenbosch Expires January 06, 2014 [Page 9] Internet-Draft Authentication, authorisation, revocation July 2013 Author's Address Bert Greevenbosch Huawei Technologies Co., Ltd. Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28978088 Email: bert.greevenbosch@huawei.com Greevenbosch Expires January 06, 2014 [Page 10]