Internet DRAFT - draft-greevenbosch-dice-authent-author-revoc
draft-greevenbosch-dice-authent-author-revoc
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]
