< draft-keoh-dice-multicast-security-03.txt   draft-keoh-dice-multicast-security-04.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: July 21, 2014 O. Garcia-Morchon Expires: August 9, 2014 O. Garcia-Morchon
E. Dijk E. Dijk
Philips Research Philips Research
January 17, 2014 A. Rahman
InterDigital
February 5, 2014
DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs) DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs)
draft-keoh-dice-multicast-security-03 draft-keoh-dice-multicast-security-04
Abstract Abstract
The CoAP and 6LoWPAN standards are fast emerging as the de-facto The CoAP and 6LoWPAN standards are fast emerging as key protocols in
protocols in the area of resource-constrained devices. Such IP-based the area of resource-constrained devices. Such IP-based systems are
systems are foreseen to be used for building and lighting control foreseen to be used for building and lighting control systems where
systems where wireless devices interconnect with each other, forming wireless devices interconnect with each other, forming low-power and
low-power and lossy networks (LLNs). Both multicast and its security lossy networks (LLNs). Both multicast and its security are key needs
are key needs in these networks. This draft presents a method for in these networks. This draft presents a method for securing IPv6
securing IPv6 multicast communication in LLNs based on the DTLS which multicast communication in LLNs based on the DTLS which is already
is already present for unicast in these CoAP devices. This draft supported for unicast communication for CoAP devices. This draft
deals with the adaptation of the DTLS record layer to protect deals with the adaptation of the DTLS record layer to protect
multicast group communication, assuming that all group members multicast group communication, assuming that all group members
already have the group security association parameters in their already have the group security association parameters in their
possession. The adapted DTLS record layer provides message possession. The adapted DTLS record layer provides message
confidentiality, integrity and replay protection to group messages confidentiality, integrity and replay protection to group messages
using the group keying material before sending the message via IPv6 using the group keying material before sending the message via IPv6
multicast to the group. multicast to the group.
Status of This Memo Status of This Memo
skipping to change at page 1, line 47 skipping to change at page 1, line 49
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 July 21, 2014. This Internet-Draft will expire on August 9, 2014.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . 9
3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 8 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Securing Multicast in LLNs . . . . . . . . . . . . . . . 9 3.2. Securing Multicast in LLNs . . . . . . . . . . . . . . . 10
4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 11 4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 11
4.1. SecurityParameter derivation . . . . . . . . . . . . . . 11 4.1. SecurityParameter derivation . . . . . . . . . . . . . . 11
4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12 4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12
4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14 4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14
4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14 4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.5. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 15
5.1. Late joiners . . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.2. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.3. Reduced sequence number space . . . . . . . . . . . . . . 16 6.1. Late joiners . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Reduced sequence number space . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
There is an increased use of wireless control networks in There is an increased use of wireless control networks in
environmental monitoring, industrial automation, lighting controls environmental monitoring, industrial automation, lighting controls
and building management systems. This is mainly driven by the fact and building management systems. This is mainly driven by the fact
that the independence from physical control wires allows for freedom that the independence from physical control wires allows for freedom
of placement, portability and for reducing the cost of installation of placement, portability and for reducing the cost of installation
as less cable placement and drilling are required. Consequently, as less cable placement and drilling are required. Consequently,
there is an ever growing number of electronic devices, sensors and there is an ever growing number of electronic devices, sensors and
skipping to change at page 3, line 19 skipping to change at page 3, line 27
with each other as well as with the wider Internet services. with each other as well as with the wider Internet services.
However, the devices in such wireless control networks are However, the devices in such wireless control networks are
characterized by power constraints (as these are usually battery- characterized by power constraints (as these are usually battery-
operated), have limited computational resources (low CPU clock, small operated), have limited computational resources (low CPU clock, small
RAM and flash storage) and often, the communication bandwidth is RAM and flash storage) and often, the communication bandwidth is
limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such
wireless control networks are also known as Low-power and Lossy wireless control networks are also known as Low-power and Lossy
Networks (LLNs). Networks (LLNs).
In addition to the usual device-to-device unicast communication that In addition to the usual device-to-device unicast communication that
would allow devices to interact with each other, group communication allow devices to directly interact with each other, group
is an important feature in LLNs. It is more effective in LLNs to communication is an important feature in LLNs. It is more effective
convey messages to a group of devices without requiring the sender to in LLNs to convey messages to a group of devices without requiring
perform multiple time and energy consuming unicast transmissions to the sender to perform multiple time and energy consuming unicast
reach each individual group member. For example, in a building and transmissions to reach each individual group member. For example, in
lighting control system, the heating, ventilation, air-conditioning a building and lighting control system, the heating, ventilation,
and lighting devices are often grouped according to the layout of the air-conditioning and lighting devices are often grouped according to
building, and control commands are issued simultaneously to a group the layout of the building, and control commands are issued
of devices. Group communication for LLNs is based on the Constrained simultaneously to a group of devices. Group communication for LLNs
Application Protocol (CoAP) [I-D.ietf-core-coap] sent over IP- is based on the Constrained Application Protocol (CoAP)
multicast [I-D.ietf-core-groupcomm]. [I-D.ietf-core-coap] sent over IP- 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 mainly used to secure a Security (DTLS) [RFC6347]. However, DTLS is currently used to secure
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 LLNs is multicast group communication. Group communication in LLNs is
equally important and should be secured as it is also vulnerable to equally important and should be secured as it is also vulnerable to
the usual attacks over the air (eavesdropping, tampering, message the usual attacks over the air (eavesdropping, tampering, message
forgery, replay, etc). Although there have been a lot of efforts in forgery, replay, etc). There have been a lot of previous efforts in
IETF to standardize mechanisms to secure multicast communication IETF to standardize mechanisms to secure multicast communication such
[RFC3830] [RFC4082] [RFC3740] [RFC4046] [RFC4535], they are not as [RFC3830], [RFC4082], [RFC3740], [RFC4046], and [RFC4535].
necessarily suitable for LLNs which have much more limited bandwidth However, these approaches are not necessarily suitable for LLNs which
and resources. For example, the MIKEY Architecture [RFC3830] is have much more limited bandwidth and resources. For example, the
mainly designed to facilitate multimedia distribution, while TESLA MIKEY Architecture [RFC3830] is mainly designed to facilitate
[RFC4082] is proposed as a protocol for broadcast authentication of multimedia distribution, while TESLA [RFC4082] is proposed as a
the source and not for protecting the confidentiality of multicast protocol for broadcast authentication of the source and not for
messages. [RFC3740] and [RFC4046] provide reference architectures protecting the confidentiality of multicast messages. [RFC3740] and
for multicast security. [RFC4535] describes Group Secure Association [RFC4046] provide reference architectures for multicast security.
Key Management Protocol (GSAKMP), a security framework for creating [RFC4535] describes Group Secure Association Key Management Protocol
and managing cryptographic groups on a network which can be reused (GSAKMP), a security framework for creating and managing
for key management in our context with any needed adaptation for cryptographic groups on a network which can be reused for key
LLNs. management in our context with any needed adaptation for LLNs.
This draft describes an approach to use DTLS as mandated in CoAP This draft describes an approach to use DTLS as mandated in CoAP
unicast to also support multicast security. We will assume that all unicast to also support multicast security. We will assume that all
devices in the group already have a group security association devices in the group already have a group security association
parameters based on a key management mechanism which is outside the parameters based on a key management mechanism which is outside the
scope of this draft. This draft specification only focuses on the scope of this draft. This draft focuses primarily on the adaptation
adaptation of DTLS record layer to protect multicast messages to be of the DTLS record layer to protect multicast messages to be sent to
sent to the group, and thus providing confidentiality, integrity and the group, and thus providing confidentiality, integrity and replay
replay protection to the CoAP group messages. protection to the CoAP group messages.
Lastly, even though this draft is written from the perspective of
securing CoAP based group communication, it is important to note that
DTLS is a powerful and flexible security protocol. Thus use of DTLS-
based multicast for application layer protocols other than CoAP are
possible as long as they follow the approach outlined in this draft.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in 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 is
authorized to transmit data to the group. In an M-to-N multicast authorized to transmit data to the group. In an M-to-N multicast
skipping to change at page 4, line 47 skipping to change at page 5, line 17
* selectors, such as source and destination transport addresses. * selectors, such as source and destination transport addresses.
* properties, such as identities. * 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: A bundling of security associations o Group Security Association (GSA): A bundling of security
(SAs) that together define how a group communicates securely. associations (SAs) that together define how a group communicates
[RFC3740] securely. [RFC3740]
o Keying material: Data that is specified as part of the SA which is o Keying material: Data that is specified as part of the SA which is
needed to establish and maintain a cryptographic security needed to establish and maintain a cryptographic security
association, such as keys, key pairs, and IVs [RFC4949]. association, such as keys, key pairs, and IVs [RFC4949].
1.2. Outline 1.2. Outline
This draft is structured as follows: Section 2 motivates the proposed This draft is structured as follows: Section 2 motivates the proposed
solution with group communication use cases in LLNs and derives a set solution with group communication use cases in LLNs and derives a set
of requirements. Section 3 provides an overview of the proposed of requirements. Section 3 provides an overview of the proposed
DTLS-based multicast security assuming that all devices in the group DTLS-based multicast security assuming that all devices in the group
already have a group security association parameters in their already have a group security association parameters in their
possession. In Section 4, we describe the details of the adaptation possession. In Section 4, we describe the details of the adaptation
of DTLS record layer for confidentiality and integrity protection of of DTLS record layer for confidentiality and integrity protection of
the multicast messages. Section 5 presents the security the multicast messages. Section 6 presents the security
considerations. considerations.
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 LLNs and the interested reader is encouraged to communication in LLNs and the interested reader is encouraged to
first read this document to understand the non-security related first read this document to understand the non-security related
details. This document also lists a few multicast group details. This document also lists a few multicast group
communication uses cases with detailed descriptions and some are communication uses cases with detailed descriptions and some are
listed here briefly: listed here briefly:
a. Lighting control: enabling synchronous operation of a group of a. Lighting control: 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 of a large group of building. This ensures that the light preset of a large group of
luminaires are changed at the same time, hence providing a visual luminaries are changed at the same time, hence providing a visual
synchronicity of light effects to the user. synchronicity of light effects to the user.
b. Firmware update: firmware of devices in a building control system b. Firmware update: firmware of devices in a building control system
are updated simultaneously, avoiding an excessive load on the LLN are updated simultaneously, avoiding an excessive load on the LLN
due to unicast firmware updates. due to unicast firmware updates.
c. Parameter update: settings of a group of similar devices are c. Parameter update: settings of a group of similar devices are
updated simultaneously and efficiently. updated simultaneously and efficiently.
d. Commissioning of above systems: information about the devices in d. Commissioning of above systems: 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, e.g. by a commissioning device. requested, e.g. by a commissioning device.
Elaborating on one of the main use cases, Lighting control, consider Elaborating on one of the main use cases, Lighting control, consider
a building equipped with 6LoWPAN IP-connected lighting devices, a building equipped with 6LoWPAN IP-connected lighting devices,
switches, and 6LoWPAN border routers; the devices are organized in switches, and 6LoWPAN border routers; the devices are organized in
groups according to their physcial location in the building, e.g., groups according to their physical location in the building, e.g.,
lighting devices and switches in a room/floor can be configured as a lighting devices and switches in a room/floor can be configured as a
single multicast group. The switches are then used to control the single multicast group. The switches are then used to control the
lighting devices in the group by sending on/off/dimming commands to lighting devices in the group by sending on/off/dimming commands to
all lighting devices in the group. 6LoWPAN border routers that are all lighting devices in the group. 6LoWPAN border routers that are
connected to an IPv6 network backbone (which is also multicast connected to an IPv6 network backbone (which is also multicast
enabled) are used to interconnect 6LoWPANs in the building. enabled) are used to interconnect 6LoWPANs in the building.
Consequently, this would also enable multicast groups to be formed Consequently, this would also enable multicast groups to be formed
across different physical subnets in the entire building. across different physical subnets in the entire building.
2.2. Security Requirements 2.2. Security Requirements
skipping to change at page 6, line 43 skipping to change at page 7, line 12
to a group of lighting devices. In more advanced lighting to a group of lighting devices. In more advanced lighting
control use cases, a N-to-M communication topology would be control use cases, a N-to-M communication topology would be
required, for example if multiple sensors (presence or day-light) required, for example if multiple sensors (presence or day-light)
are responsible to trigger events to a group of lighting devices. are 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 typical LLN usecases, the number of Senders not be always). In typical LLN use cases, the number of Senders
(normally the controlling devices) is much smaller than the (normally the controlling devices) is much smaller than the
number of Listeners (the controlled devices). A security number of Listeners (the controlled devices). A security
solution that supports 1 to 255 Senders would cover the group solution that supports 1 to 255 Senders would cover the group
sizes required for most use cases that are relevant for this sizes required for most use cases that are relevant for this
document. The number of Listeners can be larger in the range of document. The number of Listeners can be larger in the range of
2 to 5,000 devices. 2 to 5,000 devices.
c. Establishment of a Group Security Association (GSA): A secure c. Establishment of a GSA: A secure mechanism must be used to
mechanism must be used to distribute keying materials, multicast distribute keying materials, multicast security policies and
security policies and security parameters to members of a security parameters to members of a multicast group. A GSA must
multicast group. A GSA must be established by the group be established by the group controller (which manages the
controller (which manages the multicast group) among the group multicast group) among the group members. The 6LoWPAN border
members. The 6LoWPAN border router, a device in the 6LoWPAN, or router, a device in the 6LoWPAN, or a remote server outside the
a remote server outside the 6LoWPAN could play the role of the 6LoWPAN could play the role of the group controller. However,
group controller. However, GSA establishment is out-of-scope of GSA establishment is outside the scope of this draft, and it is
this draft, and it is anticipated that an activity in IETF anticipated that an activity in IETF dedicated to the design of a
dedicated to the design of a generic key management scheme for generic key management scheme for the LLN will include this
the LLN will include this feature preferably based on [RFC3740], feature preferably based on [RFC3740], [RFC4046] and [RFC4535].
[RFC4046] and [RFC4535].
d. Multicast data confidentiality: Multicast message should be 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 privacy risks to the users. pose privacy risks to the users.
e. Multicast data replay protection: It must not be possible to e. 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 f. Multicast data group authentication and integrity: It is
skipping to change at page 7, line 37 skipping to change at page 8, line 6
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 g. Multicast data security ciphersuite: All group members must use
the same ciphersuite to protect the authenticity, integrity and the same ciphersuite to protect the authenticity, integrity and
confidentiality of multicast messages. The ciphersuite is part confidentiality of multicast messages. The ciphersuite is part
of the GSA. Typically authenticity is more important than of the GSA. Typically authenticity is more important than
confidentiality in LLNs. Therefore the proposed multicast data confidentiality in LLNs. Therefore the proposed multicast data
security protocol must support atleast ciphersuites with MAC only security protocol must support at least ciphersuites with MAC
(NULL encryption) and AEAD [RFC5116] ciphersuites. Other only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other
ciphersuites that are defined for data record security in DTLS ciphersuites that are defined for data record security in DTLS
should also be preferably supported. should also be preferably supported.
h. Multicast data source authentication: Source authenticity is h. Multicast data source authentication: Source authenticity is
required if the group members are assumed to be untrusted and can required if the group members are assumed to be untrusted and can
tamper with the multicast messages. Source authenticity is not a tamper with the multicast messages. Source authenticity is not a
critical feature to be always enabled in every LLN use case. If critical feature to be always enabled in every LLN use case. If
source authenticity is required for a specific use case, then it source authenticity is required for a specific use case, then it
can be typically provided using public-key cryptography in which can be typically provided using public-key cryptography in which
every multicast message is additionally signed by each sender. every multicast message is additionally signed by each sender.
This requires much higher computational resources on both the This requires much higher computational resources on both the
sender and the receivers, thus incurring too much overhead and sender and the receivers, thus incurring too much overhead and
computational requirements on devices in LLNs. Alternatively, a computational requirements on devices in LLNs. Alternatively, a
lightweight broadcast authentication, i.e., TESLA [RFC4082] can lightweight broadcast authentication, i.e., TESLA [RFC4082] can
be deployed, however it requires devices in the multicast group be deployed, however it requires devices in the multicast group
to have a trusted clock and have the ability to loosely to have a trusted clock and have the ability to loosely
synchronize their clocks with the sender. Consequently, given synchronize their clocks with the sender. Consequently, given
that the targeted devices have limited resources, and the need that the targeted devices have limited resources, and the need
for source authenticity is not critical in every use case, source for source authenticity is not critical in every use case, source
authenticity is not performed by default as part of the proposed authenticity is not performed by default as part of the proposed
data security protocol but can be added to it using additional data security protocol. However, it can be supported using
mechanisms which are specified in this draft. It is important to additional mechanisms which are not specified in this version of
note that for use cases demanding source authenticity, additional the draft. It is important to note that for use cases demanding
security mechanism is needed to provide such guarantee. source authenticity, additional security mechanism is needed to
provide such guarantee.
i. Forward security: Devices that leave the group should not have i. Forward security: Devices that leave the group should not have
access to any future GSAs. This ensures that a past member access to any future GSAs. This ensures that a past member
device cannot continue to decrypt confidential data that is sent device cannot continue to decrypt confidential data that is sent
in the group. It also ensures that this device cannot send in the group. It also ensures that this device cannot send
encrypted and/or integrity protected data after it leaves the encrypted and/or integrity protected data after it leaves the
group. The GSA update mechanism has to be defined as part of the group. The GSA update mechanism has to be defined as part of the
key management scheme. key management scheme.
j. Backward confidentiality: A new device joining the group should j. Backward confidentiality: A new device joining the group should
not have access to any old GSAs. This ensures that a new member not have access to any old GSAs. This ensures that a new member
device cannot decrypt data sent before it joins the group. The device cannot decrypt data sent before it joins the group. The
key management scheme should ensure that the GSA is updated to key management scheme should ensure that the GSA is updated to
ensure backward confidentality. 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 over The goal of this draft is to secure CoAP Group communication over
6LoWPAN networks, by extending the use of the DTLS security protocol 6LoWPAN networks, by extending the use of the DTLS security protocol
to allow for the use of DTLS record layer with minimal adaptation. to allow for the use of DTLS record layer with minimal adaptation.
The IETF CoRE WG has selected DTLS [RFC6347] as the default must- The IETF CoRE WG has selected DTLS [RFC6347] as the default must-
implement security protocol for securing CoAP, therefore it is implement security protocol for securing CoAP, therefore it is
conceivable that DTLS can be extended to facilitate CoAP-based group desirable that DTLS be extended to facilitate CoAP-based group
communication. Reusing DTLS for different purposes while communication. Reusing DTLS for different purposes while
guaranteeing the required security properties can avoid the need to guaranteeing the required security properties can avoid the need to
implement multiple security protocols and this is especially implement multiple security protocols and this is especially
beneficial when the target deployment consists of resource- beneficial when the target deployment consists of resource-
constrained embedded devices. This section first describes group constrained embedded devices. This section first describes group
communication based on IP multicast, and subsequently sketches a communication based on IP multicast, and subsequently sketches a
solution for securing group communication using DTLS. solution for securing group communication using DTLS.
3.1. IP Multicast 3.1. IP Multicast
skipping to change at page 9, line 47 skipping to change at page 10, line 29
A group controller in an LLN creates a multicast group. The group A group controller in an LLN creates a multicast group. The group
controller may be hosted by a remote server, or a border router that controller may be hosted by a remote server, or a border router that
creates a new group over the network. In some cases, devices may be creates a new group over the network. In some cases, devices may be
configured using a commissioning tool that mediates the communication configured using a commissioning tool that mediates the communication
between the devices and the group controller. The controller in the between the devices and the group controller. The controller in the
network can be discovered by the devices using various methods network can be discovered by the devices using various methods
defined in [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and defined in [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and
Resource Directory [I-D.ietf-core-resource-directory]. The group Resource Directory [I-D.ietf-core-resource-directory]. The group
controller communicates with individual device to add them to the new controller communicates with individual device to add them to the new
group. Additionally it distributes the Group Security Association group. Additionally it distributes the GSA consisting of keying
(GSA) consisting of keying material, security policies security material, security policies security parameters and ciphersuites
parameters and ciphersuites using a standardized key management for using a standardized key management for LLN which is outside the
LLN which is out of scope of this draft. Additional ciphersuites may scope of this draft. Additional ciphersuites may need to be defined
need to be defined to convey the bulk cipher algorithm, MAC algorithm to convey the bulk cipher algorithm, MAC algorithm and key lengths
and key lengths within the key management protocol. We provide two within the key management protocol. We provide two examples of
examples of ciphersuites (based on the security requirements) that ciphersuites (based on the security requirements) that could be
could be defined as part of a future key management mechanism: defined as part of a future key management mechanism:
Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2} Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2}
Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4} Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4}
Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide
confidentiality, integrity and authenticity to the multicast messages confidentiality, integrity and authenticity to the multicast messages
where the encryption algorithm is AES [FIPS.197.2001], key length is where the encryption algorithm is AES [FIPS.197.2001], key length is
128-bit, and the authentication function is CCM [RFC6655] with a 128-bit, and the authentication function is CCM [RFC6655] with a
Message Authentication Code (MAC) length of 8 octets. Similar to Message Authentication Code (MAC) length of 8 octets. Similar to
[RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when [RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when
skipping to change at page 12, line 42 skipping to change at page 13, line 10
payload and MAC payload and MAC
The epoch is fixed by the DTLS handshake and the seq_number is The epoch is fixed by the DTLS handshake and the seq_number is
initialized to 0. The seq_number is increased by one whenever a initialized to 0. The seq_number is increased by one whenever a
sender sends a new record message. This is the mechanism of DTLS to sender sends a new record message. This is the mechanism of DTLS to
detect message replay. Finally, the message is protected (encrypted detect message replay. Finally, the message is protected (encrypted
and authenticated with a MAC) using the session keys in the "server and authenticated with a MAC) using the session keys in the "server
write" parameters. write" parameters.
One of the problems with supporting multiple senders is that, the One of the problems with supporting multiple senders is that, the
seq_number used by senders need to be syncronized to avoid their seq_number used by senders need to be synchronized to avoid their
reuse, otherwise packets sent by different senders may get discarded reuse, otherwise packets sent by different senders may get discarded
as replayed packets. Further, the bigger problem is using a single as replayed packets. Further, the bigger problem is using a single
key in a multiple sender scenario leads to nonce reuse in AEAD cipher key in a multiple sender scenario leads to nonce reuse in AEAD cipher
suites like AES-CCM [RFC6655] and AES-GCM [RFC5288] as defined in suites like AES-CCM [RFC6655] and AES-GCM [RFC5288] as defined in
DTLS. Nonce reuse can completely break the security of these cipher DTLS. Nonce reuse can completely break the security of these cipher
suites. suites.
According to the AES-CCM for TLS, Section 3 [RFC6655], the CCMNonce According to the AES-CCM for TLS, Section 3 [RFC6655], the CCMNonce
is a combination of a salt value and the sequence number. is a combination of a salt value and the sequence number.
skipping to change at page 13, line 33 skipping to change at page 13, line 46
uint64 seq_num; // TLS sequence number uint64 seq_num; // TLS sequence number
} CCMClientNonce. } CCMClientNonce.
struct { struct {
uint32 server_write_IV; // low order 32-bits uint32 server_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number uint64 seq_num; // TLS sequence number
} CCMServerNonce. } CCMServerNonce.
In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated
with the 48-bit seq_number. Therefore to prevent that the CCMNonce with the 48-bit seq_number. Therefore to prevent that the CCMNonce
is reused, either all senders need to synchronize or seperate non- is reused, either all senders need to synchronize or separate non-
overlapping sequence number spaces need to be created for each overlapping sequence number spaces need to be created for each
sender. Synchronization between senders is especially hard in LLN sender. Synchronization between senders is especially hard in LLN
and therefore we go for the second approach of seperating the and therefore we go for the second approach of separating the
sequence number spaces by embedding a unique sender identifier in the sequence number spaces by embedding a unique sender identifier in the
sequence number as suggested in [RFC5288]. sequence number as suggested in [RFC5288].
Thus in addition to configuring each device in the group with the Thus in addition to configuring each device in the group with the
GSA, the controller needs to assign a unique SenderID to each device GSA, the controller needs to assign a unique SenderID to each device
which has the sender role in the group. The size of the SenderID is which has the sender role in the group. The size of the SenderID is
1-octet based on the requirement for the supported group size 1-octet based on the requirement for the supported group size
mentioned in Section 2.2. The list of SenderIDs are then distributed mentioned in Section 2.2. The list of SenderIDs are then distributed
to all the group members by the controller. to all the group members by the controller.
skipping to change at page 15, line 11 skipping to change at page 15, line 28
the sender, which is used to check the freshness of the message the sender, which is used to check the freshness of the message
received. The listeners must ensure that the epoch is the same and received. The listeners must ensure that the epoch is the same and
trunc_seq_number in the message received is higher than the stored trunc_seq_number in the message received is higher than the stored
value, otherwise the message is discarded. Alternatively a windowing value, otherwise the message is discarded. Alternatively a windowing
mechanism can be used to accept genuine out-of-order packets. Once mechanism can be used to accept genuine out-of-order packets. Once
the authenticity and freshness of the message have been checked, the the authenticity and freshness of the message have been checked, the
listeners can pass the message to the higher layer protocols. The listeners can pass the message to the higher layer protocols. The
epoch and the trunc_seq_number in the corresponding "client read" epoch and the trunc_seq_number in the corresponding "client read"
connection state are updated as well. connection state are updated as well.
5. Security Considerations 4.5. Proxy Operation
CoAP allows a client to designate a (forward) proxy to process its
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
(and not the client) appears as the originating point to the
destination server for the CoAP request.
As mentioned in Section 11.2 of [I-D.ietf-core-coap], proxies are by
their nature men-in-the-middle and break DTLS protection of CoAP
message exchanges. Therefore, in a DTLS-based multicast scenario
involving a proxy, a two-step approach is required. First, the
client will send a unicast DTLS request to the proxy. The proxy will
then receive and decrypt the unicast message. The proxy will then
take the contents of the received message and create a new multicast
message and secure it using DTLS-based multicast before sending it
out to the group. For this approach to work properly, the client
needs to be able to designate the proxy as an authorized sender. The
mechanism for this authorization is outside the scope of this draft.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
Some of the security issues that should be taken into consideration Some of the security issues that should be taken into consideration
are discussed below. are discussed below.
5.1. Late joiners 6.1. 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, we can use the techniques
similar to AERO [I-D.mcgrew-aero] where the late joining listener on similar to AERO [I-D.mcgrew-aero] where the late joining listener on
receiving the first packet from a particular sender, initialize its receiving the first packet from a particular sender, initialize its
last seen epoch and trunc_seq_number in the "client read" state for last seen epoch and trunc_seq_number in the "client read" state for
that sender, however does not pass this packet to the application that sender, however does not pass this packet to the application
layer and instead drops it. This provides a reference point to layer and instead drops it. This provides a reference point to
identify if future packets are fresher than the last seen packet. identify if future packets are fresher than the last seen packet.
Alternatively, the group controller which can act as a listener in Alternatively, the group controller which can act as a listener in
the multicast group can maintain the epoch and trunc_seq_number of the multicast group can maintain the epoch and trunc_seq_number of
each sender. When late joiners send a request to the group each sender. When late joiners send a request to the group
controller to join the multicast group, the group controller can send controller to join the multicast group, the group controller can send
the list of epoch and trunc_seq_numbers as part of the GSA. the list of epoch and trunc_seq_numbers as part of the GSA.
5.2. Uniqueness of SenderIDs 6.2. 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 mutlicast 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
in the DTLS header to become aware of a clash. Once aware, the in the DTLS header to become aware of a clash. Once aware, the
sender can inform the controller on a secure channel about the clash sender can inform the controller on a secure channel about the clash
along with the source IP address. The controller can then provide a along with the source IP address. The controller can then provide a
different SenderID to either device or both. different SenderID to either device or both.
5.3. Reduced sequence number space 6.3. Reduced sequence number space
The DTLS record layer seq_number is truncated from 6 octets to 5 The DTLS record layer seq_number is truncated from 6 octets to 5
octets. This reduction of the seq_number space should be taken into octets. This reduction of the seq_number space should be taken into
account to ensure that epoch is incremented before the account to ensure that epoch is incremented before the
trunc_seq_number wraps over. The sender or the controller can trunc_seq_number wraps over. The sender or the controller can
increase the epoch number by sending a ChangeCipherSpec message increase the epoch number by sending a ChangeCipherSpec message
whenever the trunc_seq_number has been exhausted. This should be whenever the trunc_seq_number has been exhausted. This should be
done as part of the key management mechanism which is not defined in done as part of the key management mechanism which is not defined in
this draft. this draft.
6. Acknowledgements 7. Acknowledgements
The authors greatly acknowledge discussion, comments and feedback The authors greatly acknowledge discussion, comments and feedback
from Dee Denteneer, Peter van der Stok, Zach Shelby and Michael from Dee Denteneer, Peter van der Stok, Zach Shelby and Michael
StJohns. Additionally thank David McGrew for suggesting options for StJohns. Additionally thank David McGrew for suggesting options for
recovering from a SenderID clash, and John Foley for the extensive recovering from a SenderID clash, and John Foley for the extensive
review and pointing us to the AERO draft. We also appreciate review and pointing us to the AERO draft. We also appreciate
prototyping and implementation efforts by Pedro Moreno Sanchez who prototyping and implementation efforts by Pedro Moreno Sanchez who
worked as an intern at Philips Research. worked as an intern at Philips Research.
7. References 8. References
7.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-18 (work in progress), December
2013. 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012. Transport Layer Security (TLS)", RFC 6655, July 2012.
7.2. Informative References 8.2. Informative References
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/ <http://csrc.nist.gov/publications/fips/fips180-2/
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,
skipping to change at page 18, line 40 skipping to change at page 19, line 36
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008. Protocol", RFC 5374, November 2008.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. September 2011.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
Appendix A. Change Log
(To be removed by RFC editor before publication.)
Changes from keoh-03 to keoh-04:
o Added description of Proxy operation in a DTLS-based multicast
scenario in Section 4.5 (Proxy Operation).
o Corrected text in Section 2.2 (Security Requirements), item "h",
to indicate that multicast source authentication is not specified
in this version of the draft.
o Clarified that draft is written primarily for securing of CoAP
based group communication, but that other protocols may also be
supported if they have similar characteristics. See Section 1
(Introduction).
o Ran IETF spell checker and ID-Nits tools and corrected various
issues throughout the document.
o Various editorial updates.
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
skipping to change at line 854 skipping to change at page 21, line 4
Email: oscar.garcia@philips.com Email: oscar.garcia@philips.com
Esko Dijk Esko Dijk
Philips Research Philips Research
High Tech Campus 34 High Tech Campus 34
Eindhoven 5656 AE Eindhoven 5656 AE
NL NL
Email: esko.dijk@philips.com Email: esko.dijk@philips.com
Akbar Rahman
InterDigital
1000 Sherbrooke Street West
Montreal H3A 3G4
CA
Email: akbar.rahman@interdigital.com
 End of changes. 40 change blocks. 
103 lines changed or deleted 170 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/