< draft-keoh-dice-multicast-security-07.txt   draft-keoh-dice-multicast-security-08.txt >
DICE Working Group S. Keoh DICE Working Group S. Keoh
Internet-Draft University of Glasgow Singapore Internet-Draft University of Glasgow Singapore
Intended status: Standards Track S. Kumar, Ed. Intended status: Standards Track S. Kumar, Ed.
Expires: November 10, 2014 O. Garcia-Morchon Expires: January 4, 2015 O. Garcia-Morchon
E. Dijk E. Dijk
Philips Research Philips Research
A. Rahman A. Rahman
InterDigital InterDigital
May 9, 2014 July 03, 2014
DTLS-based Multicast Security in Constrained Environments DTLS-based Multicast Security in Constrained Environments
draft-keoh-dice-multicast-security-07 draft-keoh-dice-multicast-security-08
Abstract Abstract
The CoAP standard is fast emerging as a key protocol in the area of The CoAP standard is fast emerging as a key protocol in the area of
resource-constrained devices. Such IP-based systems are foreseen to resource-constrained devices. Such IP-based systems are foreseen to
be used for building and lighting control systems where devices be used for building and lighting automation systems where devices
interconnect with each other, forming, for example, low-power and interconnect with each other, forming, for example, low-power and
lossy networks (LLNs). Both multicast and its security are key needs lossy networks (LLNs). Both multicast and its security are key needs
in these networks. This draft presents a method for securing IPv6 in these networks. This draft presents a method for securing IPv6
multicast communication based on the DTLS which is already supported multicast communication based on the DTLS which is already supported
for unicast communication for CoAP devices. This draft deals with for unicast communication for CoAP devices. This draft deals with
the adaptation of the DTLS record layer to protect multicast group the adaptation of the DTLS record layer to protect multicast group
communication, assuming that all group members already have the group communication, assuming that all group members already have the group
security association parameters in their possession. The adapted security association parameters in their possession. The adapted
DTLS record layer provides message confidentiality, integrity and DTLS record layer provides message confidentiality, integrity and
replay protection to group messages using the group keying material replay protection to group messages using the group keying material
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 November 10, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Use Cases and Requirements . . . . . . . . . . . . . . . . . 5 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . 5
2.1. Group Communication Use Cases . . . . . . . . . . . . . . 5 2.1. Group Communication Use Cases . . . . . . . . . . . . . . 5
2.2. Security Requirements . . . . . . . . . . . . . . . . . . 6 2.2. Security Requirements . . . . . . . . . . . . . . . . . . 6
3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . 8 3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . 8
3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 9 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Securing Multicast in Constrained Networks . . . . . . . 10 3.2. Securing Multicast in Constrained Networks . . . . . . . 9
4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 11 4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 10
4.1. SecurityParameter derivation . . . . . . . . . . . . . . 11 4.1. SecurityParameter derivation . . . . . . . . . . . . . . 11
4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12 4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 11
4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14 4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 13
4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14 4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14
4.5. Unicast Responses to Multicast Messages . . . . . . . . . 15 4.5. Unicast Responses to Multicast Messages . . . . . . . . . 14
4.6. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 16 4.6. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Group level security . . . . . . . . . . . . . . . . . . 16 6.1. Group level security . . . . . . . . . . . . . . . . . . 16
6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 17 6.3. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 17
6.4. Reduced sequence number space . . . . . . . . . . . . . . 18 6.4. Reduced sequence number space . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
There is an increased use of wireless control networks in There is an increased use of wireless networks in lighting and
environmental monitoring, industrial automation, lighting controls building management systems. This is mainly driven by the fact that
and building management systems. This is mainly driven by the fact the independence from physical wires allows for freedom of placement,
that the independence from physical control wires allows for freedom portability and for reducing the cost of installation as less cable
of placement, portability and for reducing the cost of installation placement and drilling are required. Consequently, there is an ever
as less cable placement and drilling are required. Consequently, growing number of electronic devices, sensors and actuators that have
there is an ever growing number of electronic devices, sensors and become Internet connected, thus creating a trend towards the
actuators that have become Internet connected, thus creating a trend Internet-of-Things (IoT). These connected devices are equipped with
towards the Internet-of-Things (IoT). These connected devices are communication capability that enables them to interact with each
equipped with communication capability that enables them to interact other as well as with the wider Internet services. However, the
with each other as well as with the wider Internet services. devices in such wireless networks are characterized by power
However, the devices in such wireless control networks are constraints (as these are usually battery-operated), have limited
characterized by power constraints (as these are usually battery- computational resources (low CPU clock, small RAM and flash storage)
operated), have limited computational resources (low CPU clock, small and often, the communication bandwidth is limited and unreliable
RAM and flash storage) and often, the communication bandwidth is (e.g., IEEE 802.15.4 radio). Hence, such wireless networks are also
limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such known as Low-power and Lossy Networks (LLNs).
wireless control networks are also known as Low-power and Lossy
Networks (LLNs).
In addition to the usual device-to-device unicast communication that In addition to the usual device-to-device unicast communication that
allow devices to directly interact with each other, group allow devices to directly interact with each other, group
communication is an important feature in constrained environments. communication is an important feature in constrained environments.
It is more effective in constrained environments to convey messages It is more effective in constrained environments to convey messages
to a group of devices without requiring the sender to perform to a group of devices without requiring the sender to perform
multiple time and energy consuming unicast transmissions to reach multiple time and energy consuming unicast transmissions to reach
each individual group member. For example, in a building and each individual group member. For example, in a building and
lighting control system, the heating, ventilation, air-conditioning lighting automation system, the heating, ventilation, air-
and lighting devices are often grouped according to the layout of the conditioning and lighting devices are often grouped according to the
building, and control commands are issued simultaneously to a group layout of the building, and commands are issued simultaneously to a
of devices. Group communication is based on the Constrained group of devices. Group communication is based on the Constrained
Application Protocol (CoAP) [I-D.ietf-core-coap] sent over IP- Application Protocol (CoAP) [I-D.ietf-core-coap] sent over IP-
multicast [I-D.ietf-core-groupcomm]. multicast [I-D.ietf-core-groupcomm].
Currently, CoAP messages are protected using Datagram Transport Layer Currently, CoAP messages are protected using Datagram Transport Layer
Security (DTLS) [RFC6347]. However, DTLS is currently used to secure Security (DTLS) [RFC6347]. However, DTLS is currently used to secure
a connection between two endpoints and it cannot be used to protect a connection between two endpoints and it cannot be used to protect
multicast group communication. Group communication in constrained multicast group communication. Group communication in constrained
environments is equally important and should be secured as it is also environments is equally important and should be secured as it is also
vulnerable to the usual attacks over the air (eavesdropping, vulnerable to the usual attacks over the air (eavesdropping,
tampering, message forgery, replay, etc). There have been a lot of tampering, message forgery, replay, etc). There have been a lot of
skipping to change at page 4, line 42 skipping to change at page 4, line 40
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This specification uses the following terminology: This specification uses the following terminology:
o Group Controller: The entity that is responsible for creating a o Group Controller: The entity that is responsible for creating a
multicast group and establishing security associations among multicast group and establishing security associations among
authorized group members. It is also responsible for renewing/ authorized group members. It is also responsible for renewing/
updating the multicast group keys. updating the multicast group keys.
o Sender: The Sender is an entity that sends data to the multicast o Sender: The Sender is an entity that sends data to the multicast
group. In a 1-to-N multicast group only a single sender is group. In a 1-to-N multicast group only a single sender transmits
authorized to transmit data to the group. In an M-to-N multicast data to the group. In an M-to-N multicast group (where M and N
group (where M and N are not necessarily the same value), M group are not necessarily the same value), M group members are senders.
members are authorized to be senders.
o Listener: The entity that receives multicast messages when o Listener: The entity that receives multicast messages when
listening to a multicast IP address. listening to a specific multicast IP address.
o Security Association (SA): A set of policy and cryptographic keys o Security Association (SA): A set of policy and cryptographic keys
that provide security services to network traffic that matches that provide security services to network traffic that matches
that policy [RFC3740]. A Security Association usually contains that policy [RFC3740]. A Security Association usually contains
the following attributes: the following attributes:
* selectors, such as source and destination transport addresses. * selectors, such as source and destination identifiers.
* properties, such as identities.
* cryptographic policy, such as the algorithms, modes, key * cryptographic policy, such as the algorithms, modes, key
lifetimes, and key lengths used for authentication or lifetimes, and key lengths used for authentication or
confidentiality. confidentiality.
* keying material for authentication, encryption and signing. * keying material for authentication, encryption and signing.
o Group Security Association (GSA): A bundling of security o Group Security Association (GSA): A bundling of security
associations (SAs) that together define how a group communicates associations (SAs) that together define how a group communicates
securely. [RFC3740] securely. [RFC3740]
skipping to change at page 5, line 46 skipping to change at page 5, line 42
2. Use Cases and Requirements 2. Use Cases and Requirements
This section defines the use cases for group communication in LLNs This section defines the use cases for group communication in LLNs
and specifies a set of security requirements for these use cases. and specifies a set of security requirements for these use cases.
2.1. Group Communication Use Cases 2.1. Group Communication Use Cases
The "Group Communication for CoAP" draft [I-D.ietf-core-groupcomm] The "Group Communication for CoAP" draft [I-D.ietf-core-groupcomm]
provides the necessary background for multicast based CoAP provides the necessary background for multicast based CoAP
communication in constrained environments (e.g. LLNs). and the communication in constrained environments (e.g. LLNs). and the
interested reader is encouraged to first read this document to interested reader is encouraged to first read this document to
understand the non-security related details. This document also understand the non-security related details. This document also
lists a few multicast group communication uses cases with detailed lists a few multicast group communication uses cases with detailed
descriptions and some are listed here briefly: descriptions and some are listed here briefly:
a. Lighting control: enabling synchronous operation of a group of a. Lighting automation: enabling synchronous operation of a group of
6LoWPAN [RFC4944] [RFC6282] connected lights in a room/floor/ 6LoWPAN [RFC4944] [RFC6282] connected lights in a room/floor/
building. This ensures that the light preset like on/off/dim- building. This ensures that the light preset like on/off/dim-
level of a large group of luminaries are changed at the same level of a large group of luminaries are changed at the same
time, hence providing a visual synchronicity of light effects to time, hence providing a visual synchronicity of light effects to
the user. the user.
b. Parameter update: configuration settings of a group of similar b. Parameter update: configuration settings of a group of similar
devices are updated simultaneously and efficiently. devices are updated simultaneously and efficiently.
c. Device and Service discovery: information about the devices in c. Device and Service discovery: information about the devices in
the local network and their capabilities can be queried and the local network and their capabilities can be queried and
requested using multicast, e.g. by a commissioning device. The requested using multicast, e.g. by a commissioning device. The
responses are sent back in unicast. responses are sent back in unicast.
Elaborating on one of the main use cases that this document Elaborating on one of the main use cases that this document
addresses, Lighting control, consider a building equipped with addresses, Lighting automation, consider a building equipped with
6LoWPAN IP-connected lighting devices, switches, and 6LoWPAN border 6LoWPAN IP-connected lighting devices, switches, and 6LoWPAN border
routers; the devices are organized in groups according to their routers; the devices are organized in groups according to their
physical location in the building, e.g., lighting devices and physical location in the building, e.g., lighting devices and
switches in a room/floor can be configured as a single multicast switches in a room/floor can be configured as a single multicast
group. The switches are then used to control the lighting devices in group. The switches are then used to automate the lighting devices
the group by sending on/off/dimming commands to all lighting devices in the group by sending on/off/dimming commands to all lighting
in the group. 6LoWPAN border routers that are connected to an IPv6 devices in the group. 6LoWPAN border routers that are connected to an
network backbone (which is also multicast enabled) are used to IPv6 network backbone (which is also multicast enabled) are used to
interconnect 6LoWPANs in the building. Consequently, this would also interconnect 6LoWPANs in the building. Consequently, this would also
enable multicast groups to be formed across different physical enable multicast groups to be formed across different physical
subnets (which may be individually protected with L2 security). In subnets (which may be individually protected with L2 security). In
such a multicast group, group messages can traverse from one physical such a multicast group, group messages can traverse from one physical
subnet to another physical subnet through a IPv6 backbone which may subnet to another physical subnet through a IPv6 backbone which may
not be protected. Additionally, other non-lighting devices (like not be protected. Additionally, other non-lighting devices (like
window blind controls) may share the physical subnet for networking. window blind automation) may share the physical subnet for
networking.
2.2. Security Requirements 2.2. Security Requirements
The "Miscellaneous CoAP Group Communication Topics" draft The "Miscellaneous CoAP Group Communication Topics" draft
[I-D.dijk-core-groupcomm-misc] already defines a set of security [I-D.dijk-core-groupcomm-misc] already defines a set of security
requirements for CoAP group communications We re-iterate and further requirements for CoAP group communications. We re-iterate and
describe those security requirements in this section with respect to further describe those security requirements in this section with
the use cases: respect to the use cases. The security requirements are classified
into those that are assumed to be fulfilled and those that need to be
fulfilled by the solution in this draft.
The security requirements which are out-of-scope of this draft and
assumed to be already fulfilled:
a. Establishment of a GSA: A secure mechanism must be used to
distribute keying materials, multicast security policies and
security parameters to members of a multicast group. A GSA must
be established by the group controller (which manages the
multicast group) among the group members. The 6LoWPAN border
router, a device in the 6LoWPAN, or a remote server outside the
6LoWPAN could play the role of the group controller. However,
GSA establishment is outside the scope of this draft, and it is
anticipated that an activity in IETF dedicated to the design of a
generic key management scheme for the LLN will include this
feature preferably based on [RFC3740], [RFC4046] and [RFC4535].
b. Multicast data security ciphersuite: All group members must use
the same ciphersuite to protect the authenticity, integrity and
confidentiality of multicast messages. The ciphersuite is part
of the GSA. Typically authenticity is more important than
confidentiality in LLNs. Therefore the proposed multicast data
security protocol must support at least ciphersuites with MAC
only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other
ciphersuites that are defined for data record security in DTLS
should also be preferably supported.
c. Forward security: Devices that leave the group should not have
access to any future GSAs. This ensures that a past member
device cannot continue to decrypt confidential data that is sent
in the group. It also ensures that this device cannot send
encrypted and/or integrity protected data after it leaves the
group. The GSA update mechanism has to be defined as part of the
key management scheme.
d. Backward confidentiality: A new device joining the group should
not have access to any old GSAs. This ensures that a new member
device cannot decrypt data sent before it joins the group. The
key management scheme should ensure that the GSA is updated to
ensure backward confidentiality.
The security requirements which need to be fulfilled by the solution
described in this draft:
a. Multicast communication topology: We consider both 1-to-N (one a. Multicast communication topology: We consider both 1-to-N (one
sender with multiple listeners) and M-to-N (multiple senders with sender with multiple listeners) and M-to-N (multiple senders with
multiple listeners) communication topologies. The 1-to-N multiple listeners) communication topologies. The 1-to-N
communication topology is the simplest group communication communication topology is the simplest group communication
scenario that would serve the needs of a typical LLN. For scenario that would serve the needs of a typical LLN. For
example, in the simple lighting control use case, the switch is example, in the simple lighting automation use case, the switch
the only entity that is responsible for sending control commands is the only entity that is responsible for sending commands to a
to a group of lighting devices. In more advanced lighting group of lighting devices. In more advanced lighting automation
control use cases, a N-to-M communication topology would be use cases, a N-to-M communication topology would be required, for
required, for example if multiple sensors (presence or day-light) example if multiple sensors (presence or day-light) are
are responsible to trigger events to a group of lighting devices. responsible to trigger events to a group of lighting devices.
b. Multicast group size: The security solutions should support the b. Multicast group size: The security solutions should support the
typical group sizes that "Group Communication for CoAP" draft typical group sizes that "Group Communication for CoAP" draft
[I-D.ietf-core-groupcomm] intends to support. Group size is the [I-D.ietf-core-groupcomm] intends to support. Group size is the
combination of the number of Senders and Listeners in a group combination of the number of Senders and Listeners in a group
with possible overlap (a Sender can also be a Listener but need with possible overlap (a Sender can also be a Listener but need
not be always). In LLN use cases mentioned in the document, the not be always). In LLN use cases mentioned in the document, the
number of Senders (normally the controlling devices) is much number of Senders (normally the controlling devices) is much
smaller than the number of Listeners (the controlled devices). A smaller than the number of Listeners (the controlled devices). A
security solution that supports 1 to 50 Senders would cover the security solution that supports 1 to 50 Senders would cover the
group sizes required for most use cases that are relevant for group sizes required for most use cases that are relevant for
this document. The total number of group devices must be in the this document. The total number of group devices must be in the
range of 2 to 100 devices. Groups larger than these should be range of 2 to 100 devices. Groups larger than these should be
divided into smaller independent multicast groups such as divided into smaller independent multicast groups such as
grouping lights of a building per floor. grouping lights of a building per floor.
c. Establishment of a GSA: A secure mechanism must be used to c. Multicast data confidentiality: Multicast message should be
distribute keying materials, multicast security policies and
security parameters to members of a multicast group. A GSA must
be established by the group controller (which manages the
multicast group) among the group members. The 6LoWPAN border
router, a device in the 6LoWPAN, or a remote server outside the
6LoWPAN could play the role of the group controller. However,
GSA establishment is outside the scope of this draft, and it is
anticipated that an activity in IETF dedicated to the design of a
generic key management scheme for the LLN will include this
feature preferably based on [RFC3740], [RFC4046] and [RFC4535].
d. Multicast data confidentiality: Multicast message should be
encrypted, as some control commands when sent in the clear could encrypted, as some control commands when sent in the clear could
pose unforeseen privacy risks to the users of the system. pose unforeseen privacy risks to the users of the system.
e. Multicast data replay protection: It must not be possible to d. Multicast data replay protection: It must not be possible to
replay a multicast message as this would disrupt the operation of replay a multicast message as this would disrupt the operation of
the group communication. the group communication.
f. Multicast data group authentication and integrity: It is e. Multicast data group authentication and integrity: It is
essential to ensure that a multicast message originated from a essential to ensure that a multicast message originated from a
member of the group and that messages have not been tampered with member of the group and that messages have not been tampered with
by attackers who are not members. The multicast group key which by attackers who are not members. The multicast group key which
is known to all group members is used to provide authenticity to is known to all group members is used to provide authenticity to
the multicast messages (e.g., using a Message Authentication the multicast messages (e.g., using a Message Authentication
Code, MAC). This assumes that all other group members are Code, MAC). This assumes that all other group members are
trusted not to tamper with the multicast message. trusted not to tamper with the multicast message.
g. Multicast data security ciphersuite: All group members must use
the same ciphersuite to protect the authenticity, integrity and
confidentiality of multicast messages. The ciphersuite is part
of the GSA. Typically authenticity is more important than
confidentiality in LLNs. Therefore the proposed multicast data
security protocol must support at least ciphersuites with MAC
only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other
ciphersuites that are defined for data record security in DTLS
should also be preferably supported.
h. Multicast data source authentication: Source authenticity is
required if the group members are assumed to be untrusted and can
tamper with the multicast messages. This can happen if nodes of
the group can be easily compromised. Source authenticity helps
to minimize the risk of any node compromise leading to the
compromise of the whole multicast group. Source authenticity can
be typically provided using public-key cryptography in which
every multicast message is signed by the sender. Alternatively,
a lightweight broadcast authentication, i.e., TESLA [RFC4082] can
be deployed, however it requires devices in the multicast group
to have a trusted clock and have the ability to loosely
synchronize their clocks with the sender. Source authenticity
mechanisms should be preferably defined at the application layer.
The transport layer group level security can provide an
additional layer of security for the source authenticity
mechanism against DoS attacks. However, even with source
authenticity the risk still remains that compromise of a sender
can still compromise the whole group.
i. Forward security: Devices that leave the group should not have
access to any future GSAs. This ensures that a past member
device cannot continue to decrypt confidential data that is sent
in the group. It also ensures that this device cannot send
encrypted and/or integrity protected data after it leaves the
group. The GSA update mechanism has to be defined as part of the
key management scheme.
j. Backward confidentiality: A new device joining the group should
not have access to any old GSAs. This ensures that a new member
device cannot decrypt data sent before it joins the group. The
key management scheme should ensure that the GSA is updated to
ensure backward confidentiality.
3. Overview of DTLS-based Secure Multicast 3. Overview of DTLS-based Secure Multicast
The goal of this draft is to secure CoAP Group communication by The goal of this draft is to secure CoAP Group communication by
extending the use of the DTLS security protocol to allow for the use extending the use of the DTLS security protocol to allow for the use
of DTLS record layer with minimal adaptation. The IETF CoRE WG has of DTLS record layer with minimal adaptation. The IETF CoRE WG has
selected DTLS [RFC6347] as the default must-implement security selected DTLS [RFC6347] as the default must-implement security
protocol for securing CoAP, therefore it is desirable that DTLS be protocol for securing CoAP, therefore it is desirable that DTLS be
extended to facilitate CoAP-based group communication. Reusing DTLS extended to facilitate CoAP-based group communication. Reusing DTLS
for different purposes while guaranteeing the required security for different purposes while guaranteeing the required security
properties can avoid the need to implement multiple security properties can avoid the need to implement multiple security
protocols and this is especially beneficial when the target protocols and this is especially beneficial when the target
deployment consists of resource-constrained embedded devices. This deployment consists of resource-constrained embedded devices. This
section first describes group communication based on IP multicast, section first describes group communication based on IP multicast,
and subsequently sketches a solution for securing group communication and subsequently sketches a solution for securing group communication
using DTLS. using DTLS.
3.1. IP Multicast 3.1. IP Multicast
Devices in the network (e.g. LLN) are categorized into two roles, (1) Devices in the network (e.g. LLN) are categorized into two roles,
sender and (2) listener. Any node may have one of these roles, or (1) sender and (2) listener. Any node may have one of these roles,
both roles. The application(s) running on a device basically or both roles. The application(s) running on a device basically
determine these roles by the function calls they execute on the IP determine these roles by the function calls they execute on the IP
stack of the device. stack of the device.
In principle, a sender or listener does not require any prior access In principle, a sender or listener does not require any prior access
procedures or authentication to send or listen to a multicast message procedures or authentication to send or listen to a multicast message
[RFC5374]. A sender to an IPv6 multicast group sets the destination [RFC5374]. A sender to an IPv6 multicast group sets the destination
of the packet to an IPv6 address that has been allocated for IPv6 of the packet to an IPv6 address that has been allocated for IPv6
multicast. A device becomes a listener by "joining" to the specific multicast. A device becomes a listener by "joining" to the specific
IPv6 multicast group by registering with a network routing device, IPv6 multicast group by registering with a network routing device,
signaling its intent to receive packets sent to that particular IPv6 signaling its intent to receive packets sent to that particular IPv6
skipping to change at page 10, line 35 skipping to change at page 10, line 13
controller. The controller in the network can be discovered by the controller. The controller in the network can be discovered by the
devices using various methods defined in [I-D.vanderstok-core-dna] devices using various methods defined in [I-D.vanderstok-core-dna]
such as DNS-SD [RFC6763] and Resource Directory such as DNS-SD [RFC6763] and Resource Directory
[I-D.ietf-core-resource-directory]. The group controller [I-D.ietf-core-resource-directory]. The group controller
communicates with individual devices to add them to the new group. communicates with individual devices to add them to the new group.
Additionally it distributes the GSA consisting of keying material, Additionally it distributes the GSA consisting of keying material,
security policies security parameters and ciphersuites using a security policies security parameters and ciphersuites using a
standardized key management for constrained networks which is outside standardized key management for constrained networks which is outside
the scope of this draft. Additional ciphersuites may need to be the scope of this draft. Additional ciphersuites may need to be
defined to convey the bulk cipher algorithm, MAC algorithm and key defined to convey the bulk cipher algorithm, MAC algorithm and key
lengths within the key management protocol. We provide two examples lengths within the key management protocol.
of ciphersuites (based on the security requirements) that could be
defined as part of a future key management mechanism:
Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2}
Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4}
Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide
confidentiality, integrity and authenticity to the multicast messages
where the encryption algorithm is AES [FIPS.197.2001], key length is
128-bit, and the authentication function is CCM [RFC6655] with a
Message Authentication Code (MAC) length of 8 octets. Similar to
[RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when
confidentiality of multicast messages is not required, it only
provides integrity and authenticity protection to the multicast
message. When this ciphersuite is used, the message is not encrypted
but the MAC must be included in which it is computed using a HMAC
[RFC2104] that is based on Secure Hash Function SHA256
[FIPS.180-2.2002]. Depending on the future needs, other ciphersuites
with different cipher algorithms and MAC length may be supported.
Senders in the group can encrypt and authenticate the CoAP group Senders in the group can encrypt and authenticate the CoAP group
messages from the application using the keying material into the DTLS messages from the application using the keying material into the DTLS
record. The authenticated encrypted message is passed down to the record. The authenticated encrypted message is passed down to the
lower layer of the IPv6 protocol stack for transmission to the lower layer of the IPv6 protocol stack for transmission to the
multicast address as depicted in Figure 2. The listeners when multicast address as depicted in Figure 2. The listeners when
receiving the message, use the multicast IPv6 destination address and receiving the message, use the multicast IPv6 destination address and
port (i.e., Multicast identifier) to look up the GSA needed for that port (i.e., Multicast identifier) to look up the GSA needed for that
group connection. The received message is then decrypted and the group connection. The received message is then decrypted and the
authenticity is verified using the keying material for that authenticity is verified using the keying material for that
skipping to change at page 15, line 34 skipping to change at page 14, line 49
been checked, the listeners can pass the message to the higher layer been checked, the listeners can pass the message to the higher layer
protocols. The epoch and the trunc_seq_number in the corresponding protocols. The epoch and the trunc_seq_number in the corresponding
"client read" connection state are updated as well. "client read" connection state are updated as well.
4.5. Unicast Responses to Multicast Messages 4.5. Unicast Responses to Multicast Messages
In CoAP, responses to multicast messages are always sent back as In CoAP, responses to multicast messages are always sent back as
unicast. That is, the group members that receive a multicast message unicast. That is, the group members that receive a multicast message
may individually decide to send (or suppress) a unicast response as may individually decide to send (or suppress) a unicast response as
described in Section 2.5 of [I-D.ietf-core-groupcomm]. The unicast described in Section 2.5 of [I-D.ietf-core-groupcomm]. The unicast
responses to a DTLS-based multicast message may optionally be secure. responses to a DTLS-based multicast message MUST be secured.
Specifically, the unicast response may be sent back as a unicast DTLS Specifically, the unicast response may be sent back in a unicast DTLS
as described in Section 9.1 of [I-D.ietf-core-coap]. This requires message as described in Section 9.1 of [I-D.ietf-core-coap]. This
that a unicast DTLS handshake was previously initiated between the requires that a unicast DTLS session is already established between
multicast message sender and listener. the multicast sender and the listener.
Either the multicast message sender or listener may initiate the Either the multicast message sender or listener may initiate the
unicast DTLS handshake. If the DTLS handshake was initiated by the unicast DTLS handshake to establish the DTLS session. If the DTLS
multicast message sender, it requires that the sender be aware of the handshake was initiated by the multicast message sender, it requires
membership of the multicast group. This can be accomplished, for that the sender be aware of the membership of the multicast group.
example, as described in Section 2.6 of [I-D.ietf-core-coap]. If the This can be accomplished, for example, as described in Section 2.6 of
listener initiated the DTLS handshake, it may have done so, for [I-D.ietf-core-groupcomm]. If the listener initiated the DTLS
example, after receiving a multicast message for the first time. handshake, it may have done so, for example, after receiving a
multicast message from a specific sender for the first time.
In the extreme scenario, a multicast sender may attempt to initiate In the extreme scenario, a multicast sender may attempt to initiate
the unicast DTLS handshake with all, or a subset of, known listeners the unicast DTLS handshake with all, or a subset of, known listeners
just after it sends out the DTLS-based multicast message. This may just before or just after it sends out the DTLS-based multicast
result in the multicast sender having to process unicast DTLS message. This may result in the multicast sender having to process
handshake messages from multiple multicast listeners in a short unicast DTLS handshake messages from multiple multicast listeners in
period. a short period.
For matching a CoAP response to its corresponding CoAP multicast
request, the matching rules for multicast CoAP in Section 8.2 of
[I-D.ietf-core-coap] are used: only the Token value MUST match. Note
in particular that the matching rules for unicast DTLS of
Section 9.1.2 of [I-D.ietf-core-coap] do not apply in the multicast
request case.
Note: There is an obvious timing and processing load issue for the Note: There is an obvious timing and processing load issue for the
multicast sender in the scenario where it attempts to initiate the multicast sender in all scenarios where multiple DTLS sessions are
unicast DTLS handshakes with all/some of its known listeners just established just before or just after the sender sends out the DTLS-
after it sends out the DTLS-based multicast message. In this case, based multicast message. In the case that the DTLS handshake
the processing load in the multicast sender (i.e. unicast DTLS initiation is left to the listeners, the processing load in the
client) is reduced somewhat by the fact that CoAP requires a back-off multicast sender (i.e. unicast DTLS client) is reduced somewhat by
and randomization of the unicast response by the Leisure timer the fact that CoAP requires a randomized back-off delay before
mechanism as described in Section 8.2 of [I-D.ietf-core-coap]. responding to a multicast request. The delay is determined by the
Leisure mechanism as described in Section 8.2 of
[I-D.ietf-core-coap].
4.6. Proxy Operation 4.6. Proxy Operation
CoAP allows a client to designate a (forward) proxy to process its CoAP allows a client to designate a (forward) proxy to process its
CoAP request for both unicast and multicast scenarios as described in CoAP request for both unicast and multicast scenarios as described in
Section 2.10 of [I-D.ietf-core-groupcomm]. In this case, the proxy Section 2.10 of [I-D.ietf-core-groupcomm]. In this case, the proxy
(and not the client) appears as the originating point to the (and not the client) appears as the originating point to the
destination server for the CoAP request. destination server for the CoAP request.
As mentioned in Section 11.2 of [I-D.ietf-core-coap], proxies are by As mentioned in Section 11.2 of [I-D.ietf-core-coap], proxies are by
skipping to change at page 17, line 24 skipping to change at page 16, line 49
risk of compromise is reduced when deployments are in physically risk of compromise is reduced when deployments are in physically
secured locations, like lighting inside office buildings. secured locations, like lighting inside office buildings.
6.2. Late joiners 6.2. Late joiners
Listeners who are late joiners to a multicast group, do not know the Listeners who are late joiners to a multicast group, do not know the
current epoch and trun_seq_number being used by different senders. current epoch and trun_seq_number being used by different senders.
When they receive a packet from a sender with a random When they receive a packet from a sender with a random
trunc_seq_number in it, it is impossible for the listener to verify trunc_seq_number in it, it is impossible for the listener to verify
if the packet is fresh and has not been replayed by an attacker. To if the packet is fresh and has not been replayed by an attacker. To
overcome this late joiner security issue, we can use the techniques overcome this late joiner security issue, the group controller which
similar to AERO [I-D.mcgrew-aero] where the late joining listener on can act as a listener in the multicast group can maintain the epoch
receiving the first packet from a particular sender, initialize its and trunc_seq_number of each sender. When late joiners send a
last seen epoch and trunc_seq_number in the "client read" state for request to the group controller to join the multicast group, the
that sender, however does not pass this packet to the application group controller can send the list of epoch and trunc_seq_numbers as
layer and instead drops it. This provides a reference point to part of the GSA.
identify if future packets are fresher than the last seen packet.
Alternatively, the group controller which can act as a listener in
the multicast group can maintain the epoch and trunc_seq_number of
each sender. When late joiners send a request to the group
controller to join the multicast group, the group controller can send
the list of epoch and trunc_seq_numbers as part of the GSA.
6.3. Uniqueness of SenderIDs 6.3. Uniqueness of SenderIDs
It is important that SenderIDs are unique to maintain the security It is important that SenderIDs are unique to maintain the security
properties of the DTLS record layer messages. However in the event properties of the DTLS record layer messages. However in the event
that two or more senders are configured with the same SenderID, a that two or more senders are configured with the same SenderID, a
mechanism needs to be present to avoid a security weakness and mechanism needs to be present to avoid a security weakness and
recover from the situation. One such mechanism is that all senders recover from the situation. One such mechanism is that all senders
of the multicast group are also listeners. This allows a sender of the multicast group are also listeners. This allows a sender
which receives a packet from a different device with its own SenderID which receives a packet from a different device with its own SenderID
skipping to change at page 18, line 37 skipping to change at page 18, line 7
8.1. Normative References 8.1. Normative References
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (work in progress), June 2013.
[I-D.ietf-core-groupcomm] [I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP", Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-18 (work in progress), December draft-ietf-core-groupcomm-19 (work in progress), June
2013. 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 19, line 27 skipping to change at page 18, line 45
fips180-2.pdf>. fips180-2.pdf>.
[FIPS.197.2001] [FIPS.197.2001]
National Institute of Standards and Technology, "Advanced National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001, Encryption Standard (AES)", FIPS PUB 197, November 2001,
<http://csrc.nist.gov/publications/fips/fips197/ <http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>. fips-197.pdf>.
[I-D.dijk-core-groupcomm-misc] [I-D.dijk-core-groupcomm-misc]
Dijk, E. and A. Rahman, "Miscellaneous CoAP Group Dijk, E. and A. Rahman, "Miscellaneous CoAP Group
Communication Topics", draft-dijk-core-groupcomm-misc-05 Communication Topics", draft-dijk-core-groupcomm-misc-06
(work in progress), December 2013. (work in progress), June 2014.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", draft-ietf-core-resource-directory-01 (work in Directory", draft-ietf-core-resource-directory-01 (work in
progress), December 2013. progress), December 2013.
[I-D.mcgrew-aero] [I-D.mcgrew-aero]
McGrew, D. and J. Foley, "Authenticated Encryption with McGrew, D. and J. Foley, "Authenticated Encryption with
Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in
progress), February 2014. progress), February 2014.
skipping to change at page 21, line 42 skipping to change at page 21, line 10
o Added description of protection of unicast responses to multicast o Added description of protection of unicast responses to multicast
request in new Section 4.5 (Unicast Responses to Multicast request in new Section 4.5 (Unicast Responses to Multicast
Messages). Messages).
o Clarified that CoAP may be run over either LLNs or regular o Clarified that CoAP may be run over either LLNs or regular
networks. This also included changing the title of the I-D. networks. This also included changing the title of the I-D.
o Various editorial updates. o Various editorial updates.
Changes from keoh-06 to keoh-07:
o Clarified that either the sender or receiver may initiate the
unicast DTLS handshake (for the protected unicast response) in
Section 4.5.
o Various editorial updates.
Changes from keoh-07 to keoh-08:
o Changed focus of usage of the DTLS-multicast solution from
"control applications" to a "Lighting automation" theme.
o Added request/response matching rules for DTLS-multicast.
o Various editorial updates for better clarity.
Authors' Addresses Authors' Addresses
Sye Loong Keoh Sye Loong Keoh
University of Glasgow Singapore University of Glasgow Singapore
Republic PolyTechnic, 9 Woodlands Ave 9 Republic PolyTechnic, 9 Woodlands Ave 9
Singapore 838964 Singapore 838964
SG SG
Email: SyeLoong.Keoh@glasgow.ac.uk Email: SyeLoong.Keoh@glasgow.ac.uk
Sandeep S. Kumar (editor) Sandeep S. Kumar (editor)
Philips Research Philips Research
High Tech Campus 34 High Tech Campus 34
Eindhoven 5656 AE Eindhoven 5656 AE
NL NL
Email: sandeep.kumar@philips.com Email: sandeep.kumar@philips.com
Oscar Garcia-Morchon Oscar Garcia-Morchon
Philips Research Philips Research
High Tech Campus 34 High Tech Campus 34
Eindhoven 5656 AE Eindhoven 5656 AE
NL NL
Email: oscar.garcia@philips.com Email: oscar.garcia@philips.com
Esko Dijk Esko Dijk
Philips Research Philips Research
 End of changes. 39 change blocks. 
184 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/