CoRE B. Greevenbosch Internet-Draft Huawei Technologies Intended status: Informational September 06, 2013 Expires: March 10, 2014 Use cases and requirements for authentication and authorisation in CoAP draft-greevenbosch-core-authreq-00 Abstract This draft describes use cases and requirements for authenticated and authorised CoAP. The draft especially focuses on threats and their prevention. Note Discussion and suggestions for improvement are requested, and should be sent to core@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 March 10, 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 to this document. Code Components extracted from this document must Greevenbosch Expires March 10, 2014 [Page 1] Internet-Draft CoAP authentication and authorisation September 2013 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. Authorised and unauthorised devices . . . . . . . . . . . 3 3.2. Home security . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Illegal smart-meters . . . . . . . . . . . . . . . . . . 4 3.4. Maintaining and extending a network of sensors and actuators . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. Discovered compromised device . . . . . . . . . . . . . . 5 3.6. Vulnerability discovery in actuators in a chemical plant 5 3.7. Revocation of a non-compromised device . . . . . . . . . 5 3.8. Mixing nodes from different vendors . . . . . . . . . . . 6 3.9. Privacy of medical communications . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Certificate authority . . . . . . . . . . . . . . . . . . 8 5.2. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Time of revocation . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 and authorisation, as well as their expiry and revocation, in CoAP. The draft consists of the following parts: o The draft starts with several use cases. Greevenbosch Expires March 10, 2014 [Page 2] Internet-Draft CoAP authentication and authorisation September 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. The goal of the draft is to provide background material for usage when defining a solution for authorised CoAP. 3. Use cases 3.1. Authorised and unauthorised devices Company A produces sensor devices. These devices are of high quality, and no vulnerabilities have been detected. As such, they have been certified to be used in a wide area of applications. Company B produces also sensor devices. However, these devices are of low quality, and have known security issues. They failed 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 by the system. The sensors from Company A install without problem. However, for the sensors from Company B the authentication fails, and the installation of the sensors is refused. The system informs the installation engineers about the reason of failure. Fortunately the authentication mechanism revealed that the sensors from Company B are not to be used. This avoided a lot of trouble and potential security issues. 3.2. Home security Henry has an advanced home security system. The security system provides protection against burglary, as well as against fire. It has sensors on doors, motion sensors, smoke detectors, cameras etc. It also has actuators for the electronic locks, a sprinkler system and actuators that can close the gas tap and cut the electricity. The system comes with tokens. These tokens are used to turn on or off part of the system, and allow certain actions that need human interaction. One of these actions is to open or close the front door lock. Henry has provided a token to each of his family members. Greevenbosch Expires March 10, 2014 [Page 3] Internet-Draft CoAP authentication and authorisation September 2013 The system has a solid authorisation and authentication model, ensuring that only Henry and his family's tokens can drive the system. Even though the tokens can be bought in a regular store, only tokens that Henry has approved can be used in the system. Certain peripherals allow different access rights to different entities. For example, the electricity closure can only be set by Henry and the master system, whereas its on/off status can be read by all family members. All peripherals are certified by an impartial certification body, which has specified minimum security requirements. In this way, Henry is assured that when he adds a new peripheral and it is accepted by the system, it can be deemed reliable. 3.3. 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. 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.4. 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 Greevenbosch Expires March 10, 2014 [Page 4] Internet-Draft CoAP authentication and authorisation September 2013 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.5. 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.6. Vulnerability discovery in actuators in a chemical plant A chemical 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. After the discovery of the vulnerability, the chemical plant 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.7. 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. Greevenbosch Expires March 10, 2014 [Page 5] Internet-Draft CoAP authentication and authorisation September 2013 Jack fails to wreak havoc as his revenge, and neither can he sell the tokens to other adversaries. 3.8. 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. 3.9. Privacy of medical communications Mr P has developed a heart problem. To diagnose and monitor the condition of Mr P's heart, his cardiologist has requested Mr P to wear a sensor during the day. The sensor measures the heartbeat and other vital functions. The sensor transmits this information to the hospital, generally once every day. When needed, e.g. when a situation occurs that requires extra attention, the sensor can also send information ad-hoc. Protecting the integrity of the sensor readings is important, even when it is unlikely that an adversary will tamper with the sensor readings. After all, doing so would constitute a serious crime. Protecting Mr P's privacy adds significantly to the value of a solid security model in this use case. In any case eavesdropping needs to be prevented, and that includes man-in-the-middle attacks. Greevenbosch Expires March 10, 2014 [Page 6] Internet-Draft CoAP authentication and authorisation September 2013 4. Requirements This section lists requirements associated with authentication and authorisation in CoAP: 1. It SHALL be possible to verify the binding between the key and the entity associated with it. 2. It SHALL be possible to verify whether an entity is authorised to establish the connection. 3. It SHALL be possible to specify authorisation for a specific resource. 4. It SHOULD be possible to specify authorisation based on the message type. 5. It SHALL NOT be possible for an unauthorised third party to establish a cryptographic relationship. 6. There SHALL be a mechanism that allows revocation of previously granted authorisation. 7. It SHALL be possible for a receiver to determine whether a key has been revoked. 8. It SHALL be possible to perform authentication, authorisation and revocation verification fully automatically. 9. The verification technology MUST NOT require much complexity on constrained entities. 10. The verification mechanism SHALL be scalable, allowing potentially millions of entities to verify authentication and authorisation. 11. It SHOULD be possible to specify an expiry date for keys and/or authorisation. 12. It SHALL be possible to revoke compromised keys. 13. Revocation SHALL NOT require physically unplugging the device. 14. There SHALL be protection against an unauthorised third party spoofing authorisation and/or revocation of keys and entities. 15. There SHOULD be protection against denial of service (DoS) attacks, as far as it is feasible. Greevenbosch Expires March 10, 2014 [Page 7] Internet-Draft CoAP authentication and authorisation September 2013 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 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. Security considerations This whole draft concerns security considerations. It indicates use cases and requirements for authentication, authorisation and Greevenbosch Expires March 10, 2014 [Page 8] Internet-Draft CoAP authentication and authorisation September 2013 associated expiry and revocation. In addition it discusses several of the associated details and trade-offs. We refer to the rest of the draft for the complete picture. 7. IANA considerations No IANA requests are required for this document. 8. Acknowledgements Thanks to Rene Struik and Kepeng Li for their valuable feedback. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.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. 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 March 10, 2014 [Page 9]