draft-ietf-ace-usecases-02.txt | draft-ietf-ace-usecases-03.txt | |||
---|---|---|---|---|
ACE Working Group L. Seitz, Ed. | ACE Working Group L. Seitz, Ed. | |||
Internet-Draft SICS Swedish ICT AB | Internet-Draft SICS Swedish ICT AB | |||
Intended status: Informational S. Gerdes, Ed. | Intended status: Informational S. Gerdes, Ed. | |||
Expires: August 9, 2015 Universitaet Bremen TZI | Expires: September 10, 2015 Universitaet Bremen TZI | |||
G. Selander | G. Selander | |||
Ericsson | Ericsson | |||
M. Mani | M. Mani | |||
Itron | Itron | |||
S. Kumar | S. Kumar | |||
Philips Research | Philips Research | |||
February 05, 2015 | March 09, 2015 | |||
ACE use cases | ACE use cases | |||
draft-ietf-ace-usecases-02 | draft-ietf-ace-usecases-03 | |||
Abstract | Abstract | |||
Constrained devices are nodes with limited processing power, storage | Constrained devices are nodes with limited processing power, storage | |||
space and transmission capacities. These devices in many cases do | space and transmission capacities. These devices in many cases do | |||
not provide user interfaces and are often intended to interact | not provide user interfaces and are often intended to interact | |||
without human intervention. | without human intervention. | |||
This document comprises a collection of representative use cases for | This document comprises a collection of representative use cases for | |||
the application of authentication and authorization in constrained | the application of authentication and authorization in constrained | |||
environments. These use cases aim at identifying authorization | environments. These use cases aim at identifying authorization | |||
problems that arise during the lifecylce of a constrained device and | problems that arise during the lifecylce of a constrained device and | |||
are intended to provide a guideline for developing a comprehensive | are intended to provide a guideline for developing a comprehensive | |||
authentication and access control solution for this class of | authentication and authorization solution for this class of | |||
scenarios. | scenarios. | |||
Where specific details are relevant, it is assumed that the devices | Where specific details are relevant, it is assumed that the devices | |||
use the Constrained Application Protocol (CoAP) as communication | use the Constrained Application Protocol (CoAP) as communication | |||
protocol, however most conclusions apply generally. | protocol, however most conclusions apply generally. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 2, line 7 | skipping to change at page 2, line 7 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 9, 2015. | This Internet-Draft will expire on September 10, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 5 | skipping to change at page 3, line 5 | |||
2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 14 | 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 14 | |||
2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 14 | 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 14 | |||
2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 15 | 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 15 | |||
2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 15 | 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 15 | |||
2.5.4. Authorization Problems Summary . . . . . . . . . . . 16 | 2.5.4. Authorization Problems Summary . . . . . . . . . . . 16 | |||
2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 16 | 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 16 | |||
2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 17 | 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 17 | |||
2.6.2. Authorization Problems Summary . . . . . . . . . . . 17 | 2.6.2. Authorization Problems Summary . . . . . . . . . . . 17 | |||
2.7. Industrial Control Systems . . . . . . . . . . . . . . . 18 | 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 18 | |||
2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 18 | 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 18 | |||
2.7.2. Authorization Problems Summary . . . . . . . . . . . 18 | 2.7.2. Authorization Problems Summary . . . . . . . . . . . 19 | |||
3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.2. Configuration of Access Permissions . . . . . . . . . . . 20 | 3.2. Configuration of Access Permissions . . . . . . . . . . . 20 | |||
3.3. Design Considerations for Authorization Solutions . . . . 21 | 3.3. Design Considerations for Authorization Solutions . . . . 21 | |||
3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 | 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 | |||
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
7. Informative References . . . . . . . . . . . . . . . . . . . 23 | 7. Informative References . . . . . . . . . . . . . . . . . . . 23 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
skipping to change at page 4, line 11 | skipping to change at page 4, line 11 | |||
Where specific detail is necessary it is assumed that the devices | Where specific detail is necessary it is assumed that the devices | |||
communicate using CoAP [RFC7252], although most conclusions are | communicate using CoAP [RFC7252], although most conclusions are | |||
generic. | generic. | |||
1.1. Terminology | 1.1. Terminology | |||
Readers are required to be familiar with the terms defined in | Readers are required to be familiar with the terms defined in | |||
[RFC7228]. In addition, this document uses the following | [RFC7228]. In addition, this document uses the following | |||
terminology: | terminology: | |||
Resource: An item of interest. | ||||
Resource Server: The endpoint which hosts resources the Client wants | ||||
to access. Resource Servers might be located on constrained | ||||
devices. | ||||
Client: An endpoint which wants to access a resource on the Resource | ||||
Server. This could also be located on a constrained device. | ||||
Resource Owner: The subject who controls the access permissions of a | ||||
resource. | ||||
Client Owner: The subject who controls the access permissions of a | ||||
client. | ||||
Principal: A subject who is either a resource owner or a client | ||||
owner or both. | ||||
2. Use Cases | 2. Use Cases | |||
This section lists use cases involving constrained devices with | This section lists use cases involving constrained devices with | |||
certain authorization problems to be solved. Each use case first | certain authorization problems to be solved. Each use case first | |||
presents a general description of the application area, then one or | presents a general description of the application area, then one or | |||
more specific use cases, and finally a summary of the authorization- | more specific use cases, and finally a summary of the authorization- | |||
related problems principals need to be solved. | related problems users need to be solved. | |||
There are various reasons for assigning a function (client or server) | There are various reasons for assigning a function (client or server) | |||
to a device, e.g. which device initiates the conversation, how do | to a device, e.g. which device initiates the conversation, how do | |||
devices find each other, etc. The definition of the function of a | devices find each other, etc. The definition of the function of a | |||
device in a certain use case is not in scope of this document. | device in a certain use case is not in scope of this document. | |||
Readers should be aware that there might be reasons for each setting | Readers should be aware that there might be reasons for each setting | |||
and that endpoints might even have different functions at different | and that endpoints might even have different functions at different | |||
times. | times. | |||
2.1. Container monitoring | 2.1. Container monitoring | |||
skipping to change at page 5, line 41 | skipping to change at page 5, line 23 | |||
The fruit vendor's quality management wants to assure the quality of | The fruit vendor's quality management wants to assure the quality of | |||
their products and thus equips the banana boxes with sensors. The | their products and thus equips the banana boxes with sensors. The | |||
state of the goods is monitored consistently during shipment and | state of the goods is monitored consistently during shipment and | |||
ripening and abnormal sensor values are recorded. Additionally, the | ripening and abnormal sensor values are recorded. Additionally, the | |||
sensor values are used to control the climate within the cargo | sensor values are used to control the climate within the cargo | |||
containers. The sensors therefore need to communicate with the | containers. The sensors therefore need to communicate with the | |||
climate control system. Since a wrong sensor value leads to a wrong | climate control system. Since a wrong sensor value leads to a wrong | |||
temperature and thus to spoiled goods, the integrity of the sensor | temperature and thus to spoiled goods, the integrity of the sensor | |||
data must be assured. The banana boxes within a container will in | data must be assured. The banana boxes within a container will in | |||
most cases belong to the same principal. Adjacent containers might | most cases belong to the same owner. Adjacent containers might | |||
contain goods and sensors of different principals. | contain goods and sensors of different owners. | |||
The personnel that transloads the goods must be able to locate the | The personnel that transloads the goods must be able to locate the | |||
goods meant for a specific customer. However the fruit vendor does | goods meant for a specific customer. However the fruit vendor does | |||
not want to disclose sensor information pertaining to the condition | not want to disclose sensor information pertaining to the condition | |||
of the goods to other companies and therefore wants to assure the | of the goods to other companies and therefore wants to assure the | |||
confidentiality of this data. Thus, the transloading personnel is | confidentiality of this data. Thus, the transloading personnel is | |||
only allowed to access logistic information. Moreover, the | only allowed to access logistic information. Moreover, the | |||
transloading personnel is only allowed to access the data for the | transloading personnel is only allowed to access the data for the | |||
time of the transloading. | time of the transloading. | |||
skipping to change at page 6, line 21 | skipping to change at page 6, line 7 | |||
In the ripening facility bananas are stored until they are ready for | In the ripening facility bananas are stored until they are ready for | |||
selling. The banana box sensors are used to control the ventilation | selling. The banana box sensors are used to control the ventilation | |||
system and to monitor the degree of ripeness of the bananas. Ripe | system and to monitor the degree of ripeness of the bananas. Ripe | |||
bananas need to be identified and sold before they spoil. | bananas need to be identified and sold before they spoil. | |||
The supermarket chain gains ownership of the banana boxes when the | The supermarket chain gains ownership of the banana boxes when the | |||
bananas have ripened and are ready to leave the ripening facility. | bananas have ripened and are ready to leave the ripening facility. | |||
2.1.2. Authorization Problems Summary | 2.1.2. Authorization Problems Summary | |||
o U1.1 Principals such as the fruit vendor, the transloading | o U1.1 Fruit vendors, transloading personnel and container owners | |||
personnel or the container owners want to grant different access | want to grant different authorizations for their resources and/or | |||
rights for their resources to different parties and want to | endpoints to different parties. | |||
control which resource servers are allowed to present data to | ||||
their clients. | ||||
o U1.2 Principals want to grant different access rights for | o U1.2 The fruit vendor requires the integrity of the sensor data | |||
different resources on an endpoint. | that pertains the state of the goods for climate control and to | |||
ensure the quality of the monitored recordings. | ||||
o U1.3 The principals require the integrity of sensor data. | o U1.3 The container owner requires the integrity of the sensor data | |||
that is used for climate control. | ||||
o U1.4 The principals require the confidentiality of sensor data. | o U1.4 The fruit vendor requires the confidentiality of the sensor | |||
data that pertains the state of the goods. | ||||
o U1.5 The principals are not always present at the time of access | o U1.5 The fruit vendor may have several types of data that may be | |||
and cannot manually intervene in the authorization process. | controlled by the same endpoint, e.g., sensor data and the data | |||
used for logistics. | ||||
o U1.6 The principals want to grant temporary access permissions to | o U1.6 The fruit vendor requires the confidentiality of the data | |||
a party. | that is used to locate the goods. | |||
o U1.7 Messages between client and resource server might need to be | o U1.7 The fruit vendor requires the integrity of the data that is | |||
used to locate the goods. | ||||
o U1.8 The transloading personnel requires the integrity of the data | ||||
that is used to locate the goods. | ||||
o U1.9 The container owner and the fruit vendor may not be present | ||||
at the time of access and cannot manually intervene in the | ||||
authorization process. | ||||
o U1.10 The fruit vendor, container owner and transloading company | ||||
want to grant temporary access permissions to a party. | ||||
o U1.11 Messages between client and resource server might need to be | ||||
forwarded over multiple hops. | forwarded over multiple hops. | |||
o U1.8 The constrained devices might not always be able to reach the | o U1.12 The constrained devices might not always be able to reach | |||
Internet. | the Internet. | |||
2.2. Home Automation | 2.2. Home Automation | |||
Automation of the home has the potential to become a big future | Automation of the home has the potential to become a big future | |||
market for the Internet of Things. A home automation system connects | market for the Internet of Things. A home automation system connects | |||
devices in a house to the Internet and thus makes them accessible and | devices in a house to the Internet and thus makes them accessible and | |||
manageable remotely. Such devices might control for example heating, | manageable remotely. Such devices might control for example heating, | |||
ventilation, lighting, home entertainment or home security. | ventilation, lighting, home entertainment or home security. | |||
Such a system needs to accommodate a number of regular users | Such a system needs to accommodate a number of regular users | |||
skipping to change at page 10, line 12 | skipping to change at page 10, line 14 | |||
stores data on John's heart rate, which can later be accessed by a | stores data on John's heart rate, which can later be accessed by a | |||
physician to assess the condition of John's heart. | physician to assess the condition of John's heart. | |||
However John is a privacy conscious person, and is worried that Jill | However John is a privacy conscious person, and is worried that Jill | |||
might use HeartGuard to monitor his location while there is no | might use HeartGuard to monitor his location while there is no | |||
emergency. Furthermore he doesn't want his health insurance to get | emergency. Furthermore he doesn't want his health insurance to get | |||
access to the HeartGuard data, or even to the fact that he is wearing | access to the HeartGuard data, or even to the fact that he is wearing | |||
a HeartGuard, since they might refuse to renew his insurance if they | a HeartGuard, since they might refuse to renew his insurance if they | |||
decided he was too big a risk for them. | decided he was too big a risk for them. | |||
Finally John, while being comfortable with modern technology, and | Finally John, while being comfortable with modern technology and able | |||
able to operate it reasonably well, is not trained in computer | to operate it reasonably well, is not trained in computer security. | |||
security. He therefore needs an interface for the configuration of | He therefore needs an interface for the configuration of the | |||
the HeartGuard security that is easy to understand and use. If John | HeartGuard security that is easy to understand and use. If John does | |||
does not understand the meaning of a setting, he tends to leave it | not understand the meaning of a setting, he tends to leave it alone, | |||
alone, assuming that the manufacturer has initialized the device to | assuming that the manufacturer has initialized the device to secure | |||
secure settings. | settings. | |||
NOTE: Monitoring of some state parameter (e.g. an alarm button) and | NOTE: Monitoring of some state parameter (e.g. an alarm button) and | |||
the position of a person also fits well into an elderly care service. | the position of a person also fits well into an elderly care service. | |||
This is particularly useful for people suffering from dementia, where | This is particularly useful for people suffering from dementia, where | |||
the relatives or caregivers need to be notified of the whereabouts of | the relatives or caregivers need to be notified of the whereabouts of | |||
the person under certain conditions. In this case it is not the | the person under certain conditions. In this case it is not the | |||
patient that decides about access. | patient that decides about access. | |||
2.3.2. Authorization Problems Summary | 2.3.2. Authorization Problems Summary | |||
o U3.1 A principal, such as the owner of a health monitoring device, | o U3.1 The wearer of an eHealth device (John in the example above) | |||
wants to pre-configure access rights to specific data for persons | wants to pre-configure special access rights in the context of an | |||
or groups, in the context of an emergency. | emergency. | |||
o U3.2 A principal wants to selectively allow different persons or | o U3.2 The wearer of an eHealth device wants to selectively allow | |||
groups to access medical data. | different persons or groups access to medical data. | |||
o U3.3 The security measures could affect battery lifetime of the | o U3.3 The Security measures could affect battery lifetime of the | |||
devices and should changes of battery are highly inconvenient. | device and changing the battery is very inconvenient. | |||
o U3.4 Devices are often used with default access control settings. | o U3.4 Devices are often used with default access control settings. | |||
o U3.5 Principals are often not trained in computer use and | o U3.5 Wearers of eHealth devices are often not trained in computer | |||
especially computer security. | use, and especially computer security. | |||
o U3.6 Security mechanisms themselves could provide opportunities | o U3.6 Security mechanisms themselves could provide opportunities | |||
for denial of service attacks on the device. | for denial of service attacks on the device. | |||
o U3.7 The device provides a service that can be fatal for the | o U3.7 The device provides a service that can be fatal for the | |||
principal if it fails. Accordingly, the principal wants a | wearer if it fails. Accordingly, the wearer wants a security | |||
security mechanism to provide a high level of security. | mechanism to provide a high level of security. | |||
2.4. Building Automation | 2.4. Building Automation | |||
Buildings for commercial use such as shopping malls or office | Buildings for commercial use such as shopping malls or office | |||
buildings nowadays are equipped increasingly with semi-automatic | buildings nowadays are equipped increasingly with semi-automatic | |||
components to enhance the overall living quality and to save energy | components to enhance the overall living quality and to save energy | |||
where possible. This includes for example heating, ventilation and | where possible. This includes for example heating, ventilation and | |||
air condition (HVAC) as well as illumination and security systems | air condition (HVAC) as well as illumination and security systems | |||
such as fire alarms. | such as fire alarms. | |||
skipping to change at page 12, line 9 | skipping to change at page 12, line 9 | |||
Company C is provided authorization to perform the commissioning only | Company C is provided authorization to perform the commissioning only | |||
during non-office hours and only to modify configuration on devices | during non-office hours and only to modify configuration on devices | |||
belonging to the domain of Company A's space. After installation | belonging to the domain of Company A's space. After installation | |||
(wiring) of the new lighting devices, the commissioner adds the | (wiring) of the new lighting devices, the commissioner adds the | |||
devices into the company A's lighting domain. | devices into the company A's lighting domain. | |||
Once the devices are in the correct domain, the commissioner | Once the devices are in the correct domain, the commissioner | |||
authorizes the interaction rules between the new lighting devices and | authorizes the interaction rules between the new lighting devices and | |||
existing devices like presence sensors. For this, the commissioner | existing devices like presence sensors. For this, the commissioner | |||
creates the authorization rules on the BLMS which define which lights | creates the authorization rules on the BLMS which define which lights | |||
form a group and which sensors /switches/controllers are allowed to | form a group and which sensors/switches/controllers are allowed to | |||
control which groups. These authorization rules may be context based | control which groups. These authorization rules may be context based | |||
like time of the day (office or non-office hours) or location of the | like time of the day (office or non-office hours) or location of the | |||
handheld lighting controller etc. | handheld lighting controller etc. | |||
2.4.1.2. Operational | 2.4.1.2. Operational | |||
Company A's staff move into the newly furnished office space. Most | Company A's staff move into the newly furnished office space. Most | |||
lighting is controlled by presence sensors which control the lighting | lighting is controlled by presence sensors which control the lighting | |||
of specific group of lights based on the authorization rules in the | of specific group of lights based on the authorization rules in the | |||
BLMS. Additionally employees are allowed to manually override the | BLMS. Additionally employees are allowed to manually override the | |||
skipping to change at page 12, line 39 | skipping to change at page 12, line 39 | |||
shares some of the common spaces with company A. On a really hot day | shares some of the common spaces with company A. On a really hot day | |||
James who works for company A turns on the air condition in his | James who works for company A turns on the air condition in his | |||
office. Lucy who works for company B wants to make tea using an | office. Lucy who works for company B wants to make tea using an | |||
electric kettle. After she turned it on she goes outside to talk to | electric kettle. After she turned it on she goes outside to talk to | |||
a colleague until the water is boiling. Unfortunately, her kettle | a colleague until the water is boiling. Unfortunately, her kettle | |||
has a malfunction which causes overheating and results in a | has a malfunction which causes overheating and results in a | |||
smoldering fire of the kettle's plastic case. | smoldering fire of the kettle's plastic case. | |||
Due to the smoke coming from the kettle the fire alarm is triggered. | Due to the smoke coming from the kettle the fire alarm is triggered. | |||
Alarm sirens throughout the building are switched on simultaneously | Alarm sirens throughout the building are switched on simultaneously | |||
(using a broadcastor multicast) to alert the staff of both companies. | (using a broadcast or multicast) to alert the staff of both | |||
Additionally, the ventilation system of the whole building is closed | companies. Additionally, the ventilation system of the whole | |||
off to prevent the smoke from spreading and to withdraw oxygen from | building is closed off to prevent the smoke from spreading and to | |||
the fire. The smoke cannot get into James' office although he turned | withdraw oxygen from the fire. The smoke cannot get into James' | |||
on his air condition because the fire alarm overrides the manual | office although he turned on his air condition because the fire alarm | |||
setting by sending commands (broadcast or multicast) to switch off | overrides the manual setting by sending commands (broadcast or | |||
all the air conditioning. | multicast) to switch off all the air conditioning. | |||
The fire department is notified of the fire automatically and arrives | The fire department is notified of the fire automatically and arrives | |||
within a short time. After inspecting the damage and extinguishing | within a short time. After inspecting the damage and extinguishing | |||
the smoldering fire a fire fighter resets the fire alarm because only | the smoldering fire a fire fighter resets the fire alarm because only | |||
the fire department is authorized to do that. | the fire department is authorized to do that. | |||
2.4.1.3. Maintenance | 2.4.1.3. Maintenance | |||
Company A's staff are annoyed that the lights switch off too often in | Company A's staff are annoyed that the lights switch off too often in | |||
their rooms if they work silently in front of their computer. | their rooms if they work silently in front of their computer. | |||
skipping to change at page 13, line 35 | skipping to change at page 13, line 35 | |||
Company C again gets the necessary authorization from the service | Company C again gets the necessary authorization from the service | |||
company to interact with the BLMS. The commissioner now deletes any | company to interact with the BLMS. The commissioner now deletes any | |||
rules that allowed handheld controllers authorization to control the | rules that allowed handheld controllers authorization to control the | |||
lighting. Additionally the commissioner instructs the BLMS to push | lighting. Additionally the commissioner instructs the BLMS to push | |||
these new rules to prevent cached rules at the end devices from being | these new rules to prevent cached rules at the end devices from being | |||
used. | used. | |||
2.4.2. Authorization Problems Summary | 2.4.2. Authorization Problems Summary | |||
o U4.1 Principals want to be able to add a new device to their | o U4.1 The building owner and the companies want to be able to add | |||
administrative domain (commissioning). | new devices to their administrative domain (commissioning). | |||
o U4.2 Principals want to be able to integrate a device that | o U4.2 The building owner and the companies want to be able to | |||
formerly belonged to a different administrative domain to their | integrate a device that formerly belonged to a different | |||
own administrative domain (handover). | administrative domain to their own administrative domain | |||
(handover). | ||||
o U4.3 Principal want to be able to remove a device from their | o U4.3 The building owner and the companies want to be able to | |||
administrative domain (decomissioning). | remove a device from their administrative domain (decomissioning). | |||
o U4.4 Principals want to be able to delegate selected | o U4.4 The building owner and the companies want to be able to | |||
administration tasks for their devices to others. | delegate selected administration tasks for their devices to | |||
others. | ||||
o U4.5 The principal wants to be able to define context-based | o U4.5 The building owner and the companies want to be able to | |||
Authorization rules. | define context-based authorization rules. | |||
o U4.6 The principal wants to be able to revoke granted permissions | o U4.6 The building owner and the companies want to be able to | |||
and delegations. | revoke granted permissions and delegations. | |||
o U4.7 The principal wants to allow authorized entities to send data | o U4.7 The building owner and the companies want to allow authorized | |||
to their endpoints (default deny). | entities to send data to their endpoints (default deny). | |||
o U4.8 The principal wants to be able to authorize a device to | o U4.8 The building owner and the companies want to be able to | |||
control several devices at the same time using a multicast | authorize a device to control several devices at the same time | |||
protocol. | using a multicast protocol. | |||
o U4.9 Principals want to be able to interconnect their own | o U4.9 The companies want to be able to interconnect their own | |||
subsystems with those from a different operational domain while | subsystems with those from a different operational domain while | |||
keeping the control over the authorizations (e.g. granting and | keeping the control over the authorizations (e.g. granting and | |||
revoking permissions) for their endpoints and devices. | revoking permissions) for their endpoints and devices. | |||
2.5. Smart Metering | 2.5. Smart Metering | |||
Automated measuring of customer consumption is an established | Automated measuring of customer consumption is an established | |||
technology for electricity, water, and gas providers. Increasingly | technology for electricity, water, and gas providers. Increasingly | |||
these systems also feature networking capability to allow for remote | these systems also feature networking capability to allow for remote | |||
management. Such systems are in use for commercial, industrial and | management. Such systems are in use for commercial, industrial and | |||
skipping to change at page 16, line 10 | skipping to change at page 16, line 13 | |||
service operator on behalf of the utility company. One | service operator on behalf of the utility company. One | |||
responsibility of the service operator is to make sure that meter | responsibility of the service operator is to make sure that meter | |||
readings are performed and delivered to the HES. An example of a | readings are performed and delivered to the HES. An example of a | |||
Service Level Agreement between the service operator and the utility | Service Level Agreement between the service operator and the utility | |||
company is e.g. "at least 95 % of the meters have readings recorded | company is e.g. "at least 95 % of the meters have readings recorded | |||
during the last 72 hours". | during the last 72 hours". | |||
2.5.4. Authorization Problems Summary | 2.5.4. Authorization Problems Summary | |||
o U5.1 Devices are installed in hostile environments where they are | o U5.1 Devices are installed in hostile environments where they are | |||
physically accessible by attackers. Principals want to make sure | physically accessible by attackers. The service operator and the | |||
that an attacker cannot use a captured device to attack other | utility company want to make sure that an attacker cannot use a | |||
parts of their infrastructure. | captured device to attack other parts of their infrastructure. | |||
o U5.2 Principals want to restrict which entities are allowed to | o U5.2 The utility company wants to restrict which entities are | |||
send data to their resources and endpoints and thus ensure the | allowed to send data to their endpoints and to ensure the | |||
integrity of the data on their endpoints. | integrity of the data on their endpoints. | |||
o U5.3 The principal wants to control which entities are allowed to | o U5.3 The utility company wants to control which entities are | |||
read data on their resources and protect such data in transfer. | allowed to read data on their endpoints and protect such data in | |||
transfer. | ||||
o U5.4 The devices may have intermittent Internet connectivity. | o U5.4 The devices may have intermittent Internet connectivity. | |||
o U5.5 The principal is not always present at the time of access and | o U5.5 Neither the service operator nor the utility company are | |||
cannot manually intervene in the authorization process. | always present at the time of access and cannot manually intervene | |||
in the authorization process. | ||||
o U5.6 When authorization policies are updated it is impossible, or | o U5.6 When authorization policies are updated it is impossible, or | |||
at least very inefficient to contact all affected endpoints | at least very inefficient to contact all affected endpoints | |||
directly. | directly. | |||
o U5.7 Messages between a client and a resource server may need to | o U5.7 Messages between endpoints may need to be stored and | |||
be stored and forwarded over multiple nodes. | forwarded over multiple nodes. | |||
2.6. Sports and Entertainment | 2.6. Sports and Entertainment | |||
In the area of leisure time activities, applications can benefit from | In the area of leisure time activities, applications can benefit from | |||
the small size and weight of constrained devices. Sensors and | the small size and weight of constrained devices. Sensors and | |||
actuators with various functionalities can be integrated into fitness | actuators with various functionalities can be integrated into fitness | |||
equipment, games and even clothes. Principals can carry their | equipment, games and even clothes. Users can carry their devices | |||
devices around with them at all times. | around with them at all times. | |||
Usability is especially important in this area since principals will | Usability is especially important in this area since users will often | |||
often want to spontaneously interconnect their devices with others. | want to spontaneously interconnect their devices with others. | |||
Therefore the configuration of access permissions must be simple and | Therefore the configuration of access permissions must be simple and | |||
fast and not require much effort at the time of access (preferably | fast and not require much effort at the time of access (preferably | |||
none at all). | none at all). | |||
The required level of security will in most cases be low since | The required level of security will in most cases be low since | |||
security breaches will likely have less severe consequences. The | security breaches will likely have less severe consequences. The | |||
continuous monitoring of data might however enable an attacker to | continuous monitoring of data might however enable an attacker to | |||
create behavioral or movement profiles. Moreover, the aggregation of | create behavioral or movement profiles. Moreover, the aggregation of | |||
data can seriously increase the impact on the privacy of principals. | data can seriously increase the impact on the privacy of the users. | |||
2.6.1. Dynamically Connecting Smart Sports Equipment | 2.6.1. Dynamically Connecting Smart Sports Equipment | |||
Jody is a an enthusiastic runner. To keep track of her training | Jody is a an enthusiastic runner. To keep track of her training | |||
progress, she has smart running shoes that measure the pressure at | progress, she has smart running shoes that measure the pressure at | |||
various points beneath her feet to count her steps, detect | various points beneath her feet to count her steps, detect | |||
irregularities in her stride and help her to improve her posture and | irregularities in her stride and help her to improve her posture and | |||
running style. On a sunny afternoon, she goes to the Finnbahn track | running style. On a sunny afternoon, she goes to the Finnbahn track | |||
near her home to work out. She meets her friend Lynn who shows her | near her home to work out. She meets her friend Lynn who shows her | |||
the smart fitness watch she bought a few days ago. The watch can | the smart fitness watch she bought a few days ago. The watch can | |||
skipping to change at page 17, line 32 | skipping to change at page 17, line 38 | |||
Jody's shoes are allowed to access the display and measuring features | Jody's shoes are allowed to access the display and measuring features | |||
but cannot read or add training data. Jody's shoes connect to Lynn's | but cannot read or add training data. Jody's shoes connect to Lynn's | |||
watch after only a press of a button because Jody already configured | watch after only a press of a button because Jody already configured | |||
access rights for devices that belong to Lynn a while ago. | access rights for devices that belong to Lynn a while ago. | |||
After an hour, Jody gives the watch back and both girls terminate the | After an hour, Jody gives the watch back and both girls terminate the | |||
connection between their devices. | connection between their devices. | |||
2.6.2. Authorization Problems Summary | 2.6.2. Authorization Problems Summary | |||
o U6.1 The principal wants to be able to grant access rights | o U6.1 Sports equipment owners want to be able to grant access | |||
dynamically when needed. | rights dynamically when needed. | |||
o U6.2 The principle wants the configuration of access rights to | o U6.2 Sports equipment owners want the configuration of access | |||
work with very little effort. | rights to work with very little effort. | |||
o U6.3 The principal wants to be able to preconfigure access | o U6.3 Sports equipment owners want to be able to preconfigure | |||
policies that grant certain access permissions to endpoints with | access policies that grant certain access permissions to endpoints | |||
certain attributes (e.g. endpoints of a certain user) without | with certain attributes (e.g. endpoints of a certain user) without | |||
additional configuration effort at the time of access. | additional configuration effort at the time of access. | |||
o U6.4 Principals wants to protect the confidentiality of their data | o U6.4 Sports equipment owners to protect the confidentiality of | |||
for privacy reasons. | their data for privacy reasons. | |||
o U6.5 Devices might not have an Internet connection at the time of | o U6.5 Devices might not have an Internet connection at the time of | |||
access. | access. | |||
2.7. Industrial Control Systems | 2.7. Industrial Control Systems | |||
Industrial control systems (ICS) and especially supervisory control | Industrial control systems (ICS) and especially supervisory control | |||
and data acquisition systems (SCADA) use a multitude of sensors and | and data acquisition systems (SCADA) use a multitude of sensors and | |||
actuators in order to monitor and control industrial processes in the | actuators in order to monitor and control industrial processes in the | |||
physical world. Example processes include manufacturing, power | physical world. Example processes include manufacturing, power | |||
skipping to change at page 18, line 24 | skipping to change at page 18, line 27 | |||
general public how vulnerable this kind of systems are, especially | general public how vulnerable this kind of systems are, especially | |||
when connected to the Internet. The severity of these | when connected to the Internet. The severity of these | |||
vulnerabilities are exacerbated by the fact that many ICS are used to | vulnerabilities are exacerbated by the fact that many ICS are used to | |||
control critical public infrastructure, such as power, water | control critical public infrastructure, such as power, water | |||
treatment of traffic control. Nevertheless the economical advantages | treatment of traffic control. Nevertheless the economical advantages | |||
of connecting such systems to the Internet can be significant if | of connecting such systems to the Internet can be significant if | |||
appropriate security measures are put in place. | appropriate security measures are put in place. | |||
2.7.1. Oil Platform Control | 2.7.1. Oil Platform Control | |||
An oil platform uses an industrical control system to monitor data | An oil platform uses an industrial control system to monitor data and | |||
and control equipment. The purpose of this system is to gather and | control equipment. The purpose of this system is to gather and | |||
process data from a large number of sensors, and control actuators | process data from a large number of sensors, and control actuators | |||
such as valves and switches to steer the oil extraction process on | such as valves and switches to steer the oil extraction process on | |||
the platform. Raw data, alarms, reports and other information are | the platform. Raw data, alarms, reports and other information are | |||
also available to the operators, who can intervene with manual | also available to the operators, who can intervene with manual | |||
commands. Many of the sensors are connected to the controlling units | commands. Many of the sensors are connected to the controlling units | |||
by direct wire, but the operator is slowly replacing these units by | by direct wire, but the operator is slowly replacing these units by | |||
wireless ones, since this makes maintenance easier. | wireless ones, since this makes maintenance easier. | |||
The controlling units are connected to the Internet, to allow for | The controlling units are connected to the Internet, to allow for | |||
remote administration, since it is expensive and inconvenient to fly | remote administration, since it is expensive and inconvenient to fly | |||
in a technician to the platform. | in a technician to the platform. | |||
The main interest of the operator is to ensure the integrity of | The main interest of the operator is to ensure the integrity of | |||
control messages and sensor readings. The access to some resources | control messages and sensor readings. Access in some cases needs to | |||
needs to be restricted to certain clients, e.g. the operator wants | be restricted, e.g. the operator wants wireless actuators only to | |||
wireless actuators only to accept commands by authorized control | accept commands by authorized control units. | |||
units. | ||||
The owner of the platform also wants to collect auditing information | The owner of the platform also wants to collect auditing information | |||
for liability reasons. | for liability reasons. | |||
2.7.2. Authorization Problems Summary | 2.7.2. Authorization Problems Summary | |||
o U7.1 The principal wants to ensure that only authorized clients | o U7.1 The operator of the platform wants to ensure the | |||
can read data from sensors and sent commands to actuators. | confidentiality of sensor data and the integrity of actuator data. | |||
o U7.2 The principal wants to ensure that data coming from sensors | o U7.2 The operator wants to ensure that data coming from sensors | |||
and commands sent to actuators are authentic. | and commands sent to actuators are authentic. | |||
o U7.3 Some devices do not have direct Internet connection. | o U7.3 Some devices do not have direct Internet connection. | |||
o U7.4 Some devices have wired connection while others use wireless. | o U7.4 Some devices have wired connection while others use wireless. | |||
o U7.5 The execution of unauthorized commands in an ICS can lead to | o U7.5 The execution of unauthorized commands in an ICS can lead to | |||
significant financial damage, and threaten the availability of | significant financial damage, and threaten the availability of | |||
critical infrastructure services. Accordingly, the principal | critical infrastructure services. Accordingly, the operator wants | |||
wants a security solution that provides a very high level of | a security solution that provides a very high level of security. | |||
security. | ||||
3. Security Considerations | 3. Security Considerations | |||
As the use cases listed in this document demonstrate, constrained | As the use cases listed in this document demonstrate, constrained | |||
devices are used in various application areas. The appeal of these | devices are used in various application areas. The appeal of these | |||
devices is that they are small and inexpensive. That makes it easy | devices is that they are small and inexpensive. That makes it easy | |||
to integrate them into many aspects of everyday life. Therefore, the | to integrate them into many aspects of everyday life. Therefore, the | |||
devices will be entrusted with vast amounts of valuable data or even | devices will be entrusted with vast amounts of valuable data or even | |||
control functions, that need to be protected from unauthorized | control functions, that need to be protected from unauthorized | |||
access. Moreover, the aggregation of data must be considered: | access. Moreover, the aggregation of data must be considered: | |||
skipping to change at page 19, line 43 | skipping to change at page 19, line 47 | |||
device, it can be used to attack other devices as well. Due to their | device, it can be used to attack other devices as well. Due to their | |||
limited capabilities, constrained devices appear as the weakest link | limited capabilities, constrained devices appear as the weakest link | |||
in the network and hence pose an attractive target for attackers. | in the network and hence pose an attractive target for attackers. | |||
This section summarizes the security problems highlighted by the use | This section summarizes the security problems highlighted by the use | |||
cases above and provides guidelines for the design of protocols for | cases above and provides guidelines for the design of protocols for | |||
authentication and authorization in constrained RESTful environments. | authentication and authorization in constrained RESTful environments. | |||
3.1. Attacks | 3.1. Attacks | |||
This document lists security problems that principals of constrained | This document lists security problems that users of constrained | |||
devices want to solve. Further analysis of attack scenarios is not | devices want to solve. Further analysis of attack scenarios is not | |||
in scope of the document. However, there are attacks that must be | in scope of the document. However, there are attacks that must be | |||
considered by solution developers. | considered by solution developers. | |||
Because of the expected large number of devices and their ubiquity, | Because of the expected large number of devices and their ubiquity, | |||
constrained devices increase the danger from Pervasive Monitoring | constrained devices increase the danger from Pervasive Monitoring | |||
[RFC7258] attacks. | [RFC7258] attacks. | |||
As some of the use cases indicate, constrained devices may be | As some of the use cases indicate, constrained devices may be | |||
installed in hostile environments where they are physically | installed in hostile environments where they are physically | |||
skipping to change at page 20, line 40 | skipping to change at page 20, line 44 | |||
o Size of code required to run the protocol | o Size of code required to run the protocol | |||
o Size of RAM memory and stack required to run the protocol | o Size of RAM memory and stack required to run the protocol | |||
Another category of attacks that needs to be considered by solution | Another category of attacks that needs to be considered by solution | |||
developers is session interception and hijacking. | developers is session interception and hijacking. | |||
3.2. Configuration of Access Permissions | 3.2. Configuration of Access Permissions | |||
o The access control policies of the principals need to be enforced | o The access control policies need to be enforced (all use cases): | |||
(all use cases): The information that is needed to implement the | The information that is needed to implement the access control | |||
access control policies of the Principals need to be provided to | policies needs to be provided to the device that enforces the | |||
the device that enforces the authorization and applied to every | authorization and applied to every incoming request. | |||
incoming request. | ||||
o A single resource might have different access rights for different | o A single resource might have different access rights for different | |||
requesting entities (all use cases). | requesting entities (all use cases). | |||
Rationale: In some cases different types of users need different | Rationale: In some cases different types of users need different | |||
access rights, as opposed to a binary approach where the same | access rights, as opposed to a binary approach where the same | |||
access permissions are granted to all authenticated users. | access permissions are granted to all authenticated users. | |||
o A device might host several resources where each resource has its | o A device might host several resources where each resource has its | |||
own access control policy (all use cases). | own access control policy (all use cases). | |||
o The device that makes the policy decisions should be able to | o The device that makes the policy decisions should be able to | |||
evaluate context-based permissions such as location or time of | evaluate context-based permissions such as location or time of | |||
access (see e.g. Section 2.2, Section 2.3, Section 2.4). Access | access (see e.g. Section 2.2, Section 2.3, Section 2.4). Access | |||
may depend on local conditions, e.g. access to health data in an | may depend on local conditions, e.g. access to health data in an | |||
emergency. The device that makes the policy decisions should be | emergency. The device that makes the policy decisions should be | |||
able to take such conditions into account. | able to take such conditions into account. | |||
3.3. Design Considerations for Authorization Solutions | 3.3. Design Considerations for Authorization Solutions | |||
o Devices need to be enabled to enforce the principal's | o Devices need to be enabled to enforce authorization policies | |||
authorization policies without the principal's intervention at the | without human intervention at the time of the access request (see | |||
time of the access request (see e.g. Section 2.1, Section 2.2, | e.g. Section 2.1, Section 2.2, Section 2.4, Section 2.5). | |||
Section 2.4, Section 2.5). | ||||
o Authorization solutions need to consider that constrained devices | o Authorization solutions need to consider that constrained devices | |||
might not have internet access at the time of the access request | might not have internet access at the time of the access request | |||
(see e.g. Section 2.1, Section 2.3, Section 2.5, Section 2.6). | (see e.g. Section 2.1, Section 2.3, Section 2.5, Section 2.6). | |||
o It should be possible to update access control policies without | o It should be possible to update access control policies without | |||
manually re-provisioning individual devices (see e.g. | manually re-provisioning individual devices (see e.g. | |||
Section 2.2, Section 2.3, Section 2.5, Section 2.6). | Section 2.2, Section 2.3, Section 2.5, Section 2.6). | |||
Rationale: Peers can change rapidly which makes manual re- | Rationale: Peers can change rapidly which makes manual re- | |||
provisioning unreasonably expensive. | provisioning unreasonably expensive. | |||
o Principals might define authorization policies for a large number | o Authorization policies may be defined to apply to a large number | |||
of devices that might only have intermittent connectivity. | of devices that might only have intermittent connectivity. | |||
Distributing policy updates to every device for every update might | Distributing policy updates to every device for every update might | |||
not be a feasible solution (see e.g. Section 2.5). | not be a feasible solution (see e.g. Section 2.5). | |||
o It must be possible to dynamically revoke authorizations (see e.g. | o It must be possible to dynamically revoke authorizations (see e.g. | |||
Section 2.4). | Section 2.4). | |||
o The authentication and access control protocol can put undue | o The authentication and access control protocol can put undue | |||
burden on the constrained system resources of a device | burden on the constrained system resources of a device | |||
participating in the protocol. An authorization solutions must | participating in the protocol. An authorization solutions must | |||
skipping to change at page 22, line 18 | skipping to change at page 22, line 22 | |||
o Usability is important for all use cases. The configuration of | o Usability is important for all use cases. The configuration of | |||
authorization policies as well as the gaining access to devices | authorization policies as well as the gaining access to devices | |||
must be simple for the users of the devices. Special care needs | must be simple for the users of the devices. Special care needs | |||
to be taken for home scenarios where access control policies have | to be taken for home scenarios where access control policies have | |||
to be configured by users that are typically not trained in | to be configured by users that are typically not trained in | |||
security (see Section 2.2, Section 2.3, Section 2.6). | security (see Section 2.2, Section 2.3, Section 2.6). | |||
3.4. Proxies | 3.4. Proxies | |||
In some cases, the traffic between Client and Resource Server might | In some cases, the traffic between endpoints might go through | |||
go through intermediary nodes (e.g. proxies, gateways). This might | intermediary nodes (e.g. proxies, gateways). This might affect the | |||
affect the function or the security model of authentication and | function or the security model of authentication and access control | |||
access control protocols e.g. end-to-end security between Client and | protocols e.g. end-to-end security between endpoints with DTLS might | |||
Resource Server with DTLS might not be possible (see Section 2.5). | not be possible (see Section 2.5). | |||
4. Privacy Considerations | 4. Privacy Considerations | |||
Many of the devices that are in focus of this document register data | Many of the devices that are in focus of this document register data | |||
from the physical world (sensors) or affect processes in the physical | from the physical world (sensors) or affect processes in the physical | |||
world (actuators), which may involve data or processes belonging to | world (actuators), which may involve data or processes belonging to | |||
individuals. To make matters worse the sensor data may be recorded | individuals. To make matters worse the sensor data may be recorded | |||
continuously thus allowing to gather significant information about an | continuously thus allowing to gather significant information about an | |||
individual subject through the sensor readings. Therefore privacy | individual subject through the sensor readings. Therefore privacy | |||
protection is especially important, and Authentication and Access | protection is especially important, and Authentication and Access | |||
control are important tools for this, since they make it possible to | control are important tools for this, since they make it possible to | |||
control who gets access to private data. | control who gets access to private data. | |||
Privacy protection can also be weighted in when evaluating the need | Privacy protection can also be weighted in when evaluating the need | |||
for end-to-end confidentiality, since otherwise intermediary nodes | for end-to-end confidentiality, since otherwise intermediary nodes | |||
will learn the content of potentially sensitive messages sent between | will learn the content of potentially sensitive messages sent between | |||
a client and a resource server and thereby endanger the privacy of | endpoints and thereby threaten the privacy of the individual that may | |||
the individual that may be subject of this data. | be subject of this data. | |||
In some cases, even the possession of a certain type of device can be | In some cases, even the possession of a certain type of device can be | |||
confidential, e.g. principals might not want to others to know that | confidential, e.g. individuals might not want to others to know that | |||
they are wearing a certain medical device (see Section 2.3). | they are wearing a certain medical device (see Section 2.3). | |||
The personal health monitoring use case (see Section 2.3) indicates | The personal health monitoring use case (see Section 2.3) indicates | |||
the need for secure audit logs which impose specific requirements on | the need for secure audit logs which impose specific requirements on | |||
a solution. Auditing is not in the scope of ACE. However, if an | a solution. Auditing is not in the scope of ACE. However, if an | |||
authorization solution provides means for audit logs, it must | authorization solution provides means for audit logs, it must | |||
consider the impact of logged data for the privacy of the principal | consider the impact of logged data for the privacy of all parties | |||
and other parties involved. Suitable measures for protecting and | involved. Suitable measures for protecting and purging the logs must | |||
purging the logs must be taken during operation, maintenance and | be taken during operation, maintenance and decommissioning of the | |||
decommissioning of the device. | device. | |||
5. Acknowledgments | 5. Acknowledgments | |||
The authors would like to thank Olaf Bergmann, Sumit Singhal, John | The authors would like to thank Olaf Bergmann, Sumit Singhal, John | |||
Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna | Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna | |||
Schmitt, Hannes Tschofenig, Erik Wahlstroem, and Andreas Backman for | Schmitt, Hannes Tschofenig, Erik Wahlstroem, and Andreas Backman for | |||
reviewing and/or contributing to the document. Also, thanks to | reviewing and/or contributing to the document. Also, thanks to | |||
Markus Becker, Thomas Poetsch and Koojana Kuladinithi for their input | Markus Becker, Thomas Poetsch and Koojana Kuladinithi for their input | |||
on the container monitoring use case. | on the container monitoring use case. | |||
End of changes. 59 change blocks. | ||||
148 lines changed or deleted | 145 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |