Internet DRAFT - draft-greevenbosch-core-authreq
draft-greevenbosch-core-authreq
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]
