Internet DRAFT - draft-tiloca-dice-secure-groupcomm
draft-tiloca-dice-secure-groupcomm
DICE Working Group M. Tiloca
Internet-Draft S. Raza
Intended Status: Standards Track SICS Swedish ICT AB
Expires: April 16, 2016 K. Nikitin
EPFL
S. Kumar
Philips Research
October 14, 2015
Secure Two-Way DTLS-Based Group Communication in the IoT
draft-tiloca-dice-secure-groupcomm-00
Abstract
CoAP has emerged as the de-facto IoT standard for communication
involving resource-constrained devices composing Low-power and Lossy
Networks (LLNs). CoAP mandates the adoption of the DTLS protocol to
secure unicast communication. However, in several IoT application
scenarios involving a group of multiple devices, the adoption of CoAP
multicast communication through IPv6 results in a number of
advantages, especially in terms of performance and scalability. Yet,
CoAP does not specify how to secure multicast group communication in
an interoperable way. This draft presents a method to secure
communication in a multicast group, through an adaptation of the DTLS
record layer. In particular, group members rely on the same group
keying material in order to secure both request messages sent via
multicast and possible unicast messages sent as response. Since the
group keying material is provided upon joining the group, all group
members are not required to perform any DTLS handshake with each
other. The proposed method makes it possible to provide either group
authentication or source authentication of secured messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Tiloca Expires April 16, 2016 [Page 1]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
This Internet-Draft will expire on April 16, 2016.
Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 6
2.1 Group Communication Use Cases . . . . . . . . . . . . . . . 6
2.2 Security Requirements . . . . . . . . . . . . . . . . . . . 8
3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . . 10
3.1 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Two-way Secure Group Communication . . . . . . . . . . . . . 12
4. Security Data Structures . . . . . . . . . . . . . . . . . . . 13
4.1 Group Security Association . . . . . . . . . . . . . . . . . 13
4.2 Security parameter structure . . . . . . . . . . . . . . . . 15
4.3 Connection states . . . . . . . . . . . . . . . . . . . . . 16
5. Secure multicast messages . . . . . . . . . . . . . . . . . . . 18
5.1 On truncating the sequence number field . . . . . . . . . . 18
5.2 Sending secure group request messages . . . . . . . . . . . 19
5.3 Receiving secure group request messages . . . . . . . . . . 20
6. Secure unicast responses to multicast messages . . . . . . . . 21
6.1 Derivation of listener individual keying material . . . . . 22
6.2 Sending secure group response messages . . . . . . . . . . . 24
6.3 Receiving secure group response messages . . . . . . . . . . 25
7. Revocation and redistribution of group security material . . . 26
7.1 Periodical rekeying. . . . . . . . . . . . . . . . . . . . . 27
7.2 Join rekeying. . . . . . . . . . . . . . . . . . . . . . . . 28
7.3 Leave rekeying. . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 29
9.1 Group-level security . . . . . . . . . . . . . . . . . . . . 29
9.2 Prevention of attacks based on IP spoofing . . . . . . . . . 30
Tiloca Expires April 16, 2016 [Page 2]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
9.3 Nonce reuse in authenticated encryption . . . . . . . . . . 30
9.4 Late joining nodes . . . . . . . . . . . . . . . . . . . . . 31
9.5 Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . . 31
9.6 Same GroupID in different multicast groups . . . . . . . . . 32
9.7 Reduced sequence number space . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1 Normative References . . . . . . . . . . . . . . . . . . . 32
10.2 Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1 Introduction
Nowadays it is possible to connect the physical and cyber world by
embedding a tiny computer, with limited storage and communication
capabilities, in everyday physical objects. The resultant smart
objects can be connected not only with each other in Low-Power and
Lossy Networks (LLNs), but also with the Internet, so actively taking
part to the Internet of Things (IoT). In the IoT, smart objects can
interact with each other through different communication paradigms,
namely one-to-one, one-to-many, and many-to-many. Besides, different
communication and networking protocols are standardized to enable
interactions between smart objects. For instance, 6LoWPAN [RFC6282]
enables IP capabilities, RPL [RFC6550] enables routing capabilities,
and CoAP [RFC7252] enables web capabilities.
In particular, CoAP has become the de-facto web standard for the IoT,
and mandates the adoption of the DTLS protocol [RFC6347] to provide
secure communication, if requested. More recently, [RFC7390] has
enabled group communication for CoAP, highlighting various use cases
where smart objects benefit from a group communication model. There
are multiple use cases where secure group communication is highly
convenient or even inevitable, such as lightening control, integrated
building control, software and firmware updates, parameter and
configuration updates, commissioning of 6LoWPAN networks, and
emergency broadcasts. While in several real-world IoT deployments
such use cases require security as well, CoAP does not currently
specify how to secure multicast group communication.
Since DTLS is the mandated security protocol for unicast
communication in the IoT, it makes particular sense to extend DTLS in
order to enable secure multicast communication among smart objects.
Although IPsec multicast [RFC5374] is a possible alternative, it
would require to adopt additional heavyweight security protocols such
as IPsec [RFC4301][RFC6040] and likely even IKEv2 [RFC7296].
Moreover, since unicast communication in the IoT is supposed to be
protected through DTLS, switching to a full adoption of solutions
based on IPsec becomes even less convenient and practical.
Tiloca Expires April 16, 2016 [Page 3]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
There were previous attempts to enable secure DTLS-based group
communication [I-D.keoh-dice-multicast-security-08][I-D.kumar-dice-
multicast-security-00] for CoAP. However, they were questioned due to
a number of reasons. First, more relevant use uses cases were
expected to be provided and more strongly motivated. Second, since
group authentication may be not enough for many use cases, source
authentication was pointed out as a fundamental option to be
available. Third, the initial lack of protection for group response
messages was covered by adopting traditional DTLS unicast session.
This is prone to practical issues and can result in performance
degradation, especially on large scale, dynamic, groups. Following
the discussions around previous proposals, there is a consensus that
secure group communication is indeed necessary and desirable, but
specific methods proposed so far to achieve it were questioned.
In this draft, we propose an approach providing secure two-way DTLS-
based group communication in the IoT, overcoming the limitations of
previous proposals. This draft particularly focuses on the following
goals: i) avoiding the need to implement multiple security protocols,
by extending the DTLS record layer; ii) protecting multicast request
messages as well as related unicast response messages in the group;
iii) making it possible to ensure source or group authentication of
both group request messages and group response messages; and iv)
avoiding any DTLS handshake to enable secure group communication.
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:
o Keying material: Data that is necessary to establish and maintain
a cryptographic security association. This includes, for instance,
keys, key pairs, and IVs [RFC4949].
o Security Association (SA): Set of policies and cryptographic
keying material that together provide security services to network
traffic matching this policy [RFC3740]. In this draft, a Security
Association includes, together with possible additional ones, the
following attributes:
* selectors, e.g. source and destination transport addresses;
* properties, such as identities of involved entities;
* cryptographic policy, e.g. the algorithms, modes, key
Tiloca Expires April 16, 2016 [Page 4]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
lifetimes, and key lengths used for the authentication or
confidentiality processes;
* keying material used for the authentication, encryption and
signing processes.
o Group Security Association: A bundling of security associations
(SAs) that together define how members of a multicast group
communicate securely [RFC3740].
o Group Controller (GC): Entity responsible for creating a multicast
group, establishing security associations among authorized group
members, and managing the joining of new group members. This
entity may also be responsible for renewing/updating multicast
group keys and related policies, i.e. act as group key manager.
The GC is not required to be an actual member of the multicast
group and to take part in the group communication.
o Sender: Entity in a multicast group that sends data as multicast
messages to the group. In a 1-to-N multicast group, only a single
sender transmits data to the group; in an M-to-N multicast group
(where M and N do not necessarily have the same value), M group
members are senders.
o Listener: Entity in a multicast group that receives multicast
messages when listening to the multicast IPv6 address associated
to the multicast group. A listener MAY reply back, by sending a
unicast response message to the sender which has sent the
multicast message.
o Group request: Multicast message sent by a sender in the group to
all listeners in the group through multicast IPv6.
o Group response: Unicast message sent back by a listener node in
the group as a response to a group request received by a sender.
o Group authentication: Evidence that a received message originated
from some member of this group. This provides assurances that the
message was not tampered with by an adversary outside this group,
but does not pinpoint and/or assure what specific entity in the
group originated the message.
o Source authentication: Evidence that a received message originated
from a specifically identified group member. This provides
assurances that the message was not tampered with by any other
group member or an adversary outside this group.
1.2 Outline
Tiloca Expires April 16, 2016 [Page 5]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
The remainder of this draft is organized as follows. Section 2
describes some relevant group communication use cases in the IoT and
identifies a set of security requirements. Section 3 overviews the
proposed two-way DTLS-based secure group communication, assuming that
the group members already have in their possession everything
required to fully operate. Section 4 presents the security data
structures referred throughout this draft. Then, Sections 5 and 6
describe the details of the adaptation of the DTLS record layer, to
secure multicast request messages and unicast reply messages,
respectively. Section 7 discusses considerations related to the
revocation and redistribution of security material in the multicast
group. Section 9 presents the security considerations.
2. Use Cases and Requirements
This section introduces some use cases for group communication in the
IoT and identifies a set of related security requirements.
2.1 Group Communication Use Cases
"Group Communication for CoAP" [RFC7390] provides the necessary
background for multicast-based CoAP communication, with particular
reference to low-power and lossy networks (LLNs) and resource
constrained devices. The interested reader is encouraged to first
read this document to understand the non-security related details.
This document also lists a few group communication use cases with
detailed descriptions.
a. Lighting control: consider a building equipped with 6LoWPAN
[RFC4944][RFC6282] IP-connected lighting devices, switches, and
6LoWPAN border routers. The devices are organized into groups
according to their physical location in the building. For
instance, lighting devices and switches in a room or corridor can
be configured as members of a single multicast group. Switches are
then used to control the lighting devices, by sending
on/off/dimming commands to all lighting devices in a group.
6LoWPAN border routers that are connected to an IPv6 network
backbone (which is also multicast-enabled) are used to
interconnect 6LoWPAN routers in the building. Consequently, this
would also enable logical multicast groups to be formed even if
devices in the lighting group may be physically in different
subnets (e.g. on wired and wireless networks). Group communication
enables synchronous operation of a group of 6LoWPAN connected
lights, ensuring that the light preset (e.g. dimming level or
color) of a large group of luminaires are changed at the same
perceived time. This is especially useful for providing a visual
synchronicity of light effects to the user. Devices may reply back
to the switches that issue on/off/dimming commands, in order to
Tiloca Expires April 16, 2016 [Page 6]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
report about the execution of the requested operation (e.g. OK,
failure, error) and their current operational status.
b. Integrated building control: enabling Building Automation and
Control Systems (BACSs) to control multiple heating, ventilation
and air-conditioning units to pre-defined presets. Controlled
units can be organized into multicast groups in order to reflect
their physical position in the building, e.g. devices in the same
room can be configured as members of a single multicast group.
Furthermore, controlled units are expected to possibly reply back
to the BACS issuing control commands, in order to report about the
execution of the requested operation (e.g. OK, failure, error) and
their current operational status.
c. Software and firmware updates: software and firmware updates often
comprise quite a large amount of data. Therefore, it can overload
an LLN that is otherwise typically used to deal with only small
amounts of data, on an infrequent base. Rather than sending
software and firmware updates as unicast messages to each
individual device, multicasting such updated data to a larger
group of devices at once displays a number of benefits. For
instance, it can significantly reduce the network load and
decrease the overall time latency for propagating this data to all
devices. Even if the complete whole update process itself is
secured, securing the individual messages is important, in case
updates consist of relatively large amounts of data. In fact,
checking individual received data piecemeal for tampering avoids
that devices store large amounts of partially corrupted data and
that they detect tampering hereof only after all data has been
received. Devices receiving software and firmware updates are
expected to possibly reply back, in order to provide a feedback
about the execution of the update operation (e.g. OK, failure,
error) and their current operational status.
d. Parameter and configuration update: by means of multicast
communication, it is possible to update the settings of a group of
similar devices, both simultaneously and efficiently. Possible
parameters are related, for instance, to network load management
or network access controls. Devices receiving parameter and
configuration updates are expected to possibly reply back, to
provide a feedback about the execution of the update operation
(e.g. OK, failure, error) and their current operational status.
e. Commissioning of LLNs systems: a commissioning device is
responsible for querying all devices in the local network or a
selected subset of them, in order to discover their presence, and
be aware of their capabilities, default configuration, and
operating conditions. Queried devices displaying similarities in
Tiloca Expires April 16, 2016 [Page 7]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
their capabilities and features, or sharing a common physical
location can be configured as members of a single multicast group.
Queried devices are expected to reply back to the commissioning
device, in order to notify their presence, and provide the
requested information and their current operational status.
f. Emergency broadcast: a particular emergency related information
(e.g. natural disaster) is generated and broadcast by an emergency
notifier, and relayed to multiple devices. The latters may reply
back to the emergency notifier, in order to provide their feedback
and local information related to the ongoing emergency.
2.2 Security Requirements
The following security requirements are out of the scope of this
draft and are assumed to be already fulfilled:
a. Establishment of a GSA: A secure mechanism must be used to
distribute keying material, 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 network, or a remote server outside the
6LoWPAN network, could play the role of the Group Controller.
However, the GSA establishment is out of 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][RFC4535].
b. Multicast data security ciphersuite: All group members MUST agree
on a ciphersuite to provide authenticity, integrity and
confidentiality of messages in the multicast group. The
ciphersuite is specified as part of the GSA. Typically,
authenticity is more important than confidentiality in LLNs.
Therefore, the approach described in this draft MUST support at
least ciphersuites with MAC only (NULL encryption) and AEAD
[RFC5116] ciphersuites. Other ciphersuites defined for data record
security in DTLS SHOULD also be preferably supported.
c. Backward security: A new device joining the multicast group should
not have access to any old GSAs used before its joining. This
ensures that a new group member is not able to decrypt
confidential data sent before it has joined the group. The adopted
key management scheme should ensure that the GSA is updated to
ensure backward confidentiality. The actual mechanism to update
the GSA and renew the group keying material upon a group member's
joining has to be defined as part of the group key management
scheme.
Tiloca Expires April 16, 2016 [Page 8]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
d. Forward security: Entities that leave the multicast group should
not have access to any future GSAs or message exchanged within the
group after their leaving. This ensures that a former group member
is not able to decrypt confidential data sent within the group
anymore. Also, it ensures that a former member is not able to send
encrypted and/or integrity protected messages to the group
anymore. The actual mechanism to update the GSA and renew the
group keying material upon a group member's leaving has to be
defined as part of the group key management scheme.
The following security requirements need to be fulfilled by the
approach described in this draft:
a. Multicast communication topology: This draft considers both 1-to-N
(one sender and multiple listeners) and M-to-N (multiple senders
and multiple listeners) communication topologies. The 1-to-N
communication topology is the simplest group communication
scenario that would serve the needs of a typical LLN. For
instance, in the lighting control use case, switches are the only
entities responsible for sending commands to a group of lighting
devices. In more advanced lighting control use cases, a M-to-N
communication topology would be required, for instance in case
multiple sensors (presence or day-light) are responsible to
trigger events to a group of lighting devices.
b. Multicast group size: Security solutions for group communication
SHOULD be able to adequately support different, possibly large,
group sizes. Group size is the combination of the number of
senders and listeners in a multicast group, with possible overlap
(i.e. a sender MAY also be a listener at the same time). In the
use cases mentioned in this draft, the number of senders (normally
the controlling devices) is much smaller than the number of
listeners (i.e. the controlled devices). A security solution for
group communication that supports 1 to 50 senders would be able to
properly cover the group sizes required for most use cases that
are relevant for this draft. The total number of group members is
expected to be in the range of 2 to 100 devices. Groups larger
than that SHOULD be divided into smaller independent multicast
groups, e.g. by grouping lights in a building on a per floor
basis.
c. Data replay protection: It MUST NOT be possible to replay a group
request message or group response message, which would disrupt the
correct communication in the group and the activity of group
members.
d. Group-level data confidentiality: Messages sent within the
multicast group SHOULD be encrypted. In fact, some control
Tiloca Expires April 16, 2016 [Page 9]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
commands and/or associated responses could pose unforeseen
security and privacy risks to the system users, when sent as
plaintext. In particular, data confidentiality MAY be required if
privacy sensitive data is exchanged in the group. This draft
considers group-level data confidentiality since messages are
encrypted at a group level, i.e. in such a way that they can be
decrypted by any member of the multicast group, but not by an
external adversary or other external entities.
e. Data authentication: Messages sent within the multicast group
SHOULD be authenticated. That is, it is essential to ensure that a
message is originated by a generic member of the group (group-
level data authentication) or a specific member of the group
(source-level data authentication). The approach proposed in this
draft makes it possible to provide group-level data authentication
or source-level data authentication, both for group requests
originated by sender nodes and group responses originated by
listener nodes. In case group-level data authentication is
considered, it is assumed that all group members are trusted not
to tamper with the messages sent within the group, and the common
group keying material is used to authenticate messages. In case
source-level data authentication is considered, messages are
signed by their respective originator group member by means of
public-key cryptography.
f. Data integrity: Messages sent within the multicast group SHOULD be
integrity protected. That is, it is essential to ensure that a
message has not been tampered with by an external adversary or
other external entities which are not group members. Data
integrity is provided through the same means used to provide data
authentication.
3. Overview of DTLS-based Secure Multicast
This draft describes how to adapt the DTLS protocol to secure group
communication. To this end, we propose an extension of DTLS, based on
minimal adaptation to the DTLS record layer [RFC6347]. Reusing the
DTLS protocol for different purposes can guarantee the required level
of security, while avoiding the need to implement multiple security
protocols. This is especially beneficial when the target deployment
consists of embedded, resource-constrained, devices.
DTLS has been selected as the default, must-implement, security
protocol for securing communication relying on the CoAP protocol
[RFC7252]. Therefore, it is desirable that DTLS is also accordingly
extended to secure CoAP-based group communication [RFC7390].
Nevertheless, the DTLS extension described in this draft does not
imply the usage of the CoAP protocol. That is, different protocols
Tiloca Expires April 16, 2016 [Page 10]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
can be adopted at the application level, provided that they support
the presence of DTLS.
This section first presents group communication based on IPv6
multicast, and then overviews a possible adaptation of DTLS to secure
group communication. In particular, the proposed approach makes it
possible to secure group request sent by senders as multicast
messages and related group responses sent back by listeners as
unicast messages. Also, it makes it possible to provide source
authenticity of group messages, both for group requests and group
responses. Finally, unless otherwise necessary to establish further
specific secure sessions, the proposed approach does not require to
perform any DTLS handshake between group members.
3.1 IPv6 Multicast
Group members are categorized into two possible roles, namely sender
and listener. Any group member may have one of these roles, or both
roles. The application(s) running on a group member is supposed to
determine these roles, depending on the intended interactions with
the communication stack. In principle, a sender or listener does not
require any prior access procedures or authentication to send or
listen to a multicast message [RFC5374].
++++
|. |
--| ++++
++++ / ++|. |
|A |---------| ++++
| | \ ++|B |
++++ \-----| |
Sender ++++
Listeners
Figure 1: Example of a 1-to-N multicast communication
A sender to an IPv6 multicast group sets the destination of the
packet to an IPv6 address that has been allocated for IPv6 multicast.
A device becomes a listener by "joining" to the specific IPv6
multicast group. This in turn requires the joining device to register
with a network routing device, signaling the intent to receive
packets sent to that particular IPv6 multicast group. Figure 1
depicts an example of 1-to-N multicast communication and the roles of
the group members. In principle, any device can decide to listen to
any IPv6 multicast address. This also means that applications on the
other group members do not know, or do not get notified, when new
listeners join the multicast group. More details on the IPv6
multicast and CoAP group communication can be found in [RFC7390].
Tiloca Expires April 16, 2016 [Page 11]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
This draft does not intend to modify any of the underlying group
communication or multicast routing protocols.
3.2 Two-way Secure Group Communication
This draft assumes the presence of a group controller (GC), i.e. a
dedicated entity that creates and manages the multicast group. The
group controller may be hosted by a remote server or be a border
router. In some cases, devices that intend to join the multicast
group may be configured by means of a commissioning tool that
mediates the communication between them and the group controller.
Devices can discover the group controller by using various methods
defined in [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and
Resource Directory [I-D.ietf-core-resource-directory]. The group
controller communicates with individual devices to add them to the
group. Additionally it provides them with the GSA, consisting of the
keying material, security policies, security parameters and
ciphersuites. To this end, the group controller relies on
standardized key management mechanisms which are out of the scope of
this draft. Additional ciphersuites may need to be defined to convey
the bulk cipher algorithm, MAC algorithm and key lengths within the
key management protocol.
A sender in the multicast group encrypts and authenticates a group
request multicast message by using the group keying material to
process the DTLS record. Then, the group request is passed down to
the lower layer of the IP protocol stack for transmission to the
multicast address as depicted in Figure 2. Upon receiving the group
request, the listeners use the multicast IP destination address and
port number (i.e., Multicast identifier) to look up the GSA
associated to that group connection. The received group request is
then decrypted and its authenticity is verified. More details about
how group requests are processed in the multicast group are provided
in Section 5.
A listener MAY reply back to the sender that originated the group
response, by means of a unicast group response message. The listener
secures the group response by means of individual keying material
derived from the group keying material in the GSA and used to process
the DTLS record. Then, the group response is passed down to the lower
layer of the IP protocol stack for transmission to the unicast
address of the sender, as depicted in Figure 2. Upon receiving the
group response, the sender considers the group keying material in the
GSA, and uses it to derive the individual keying material associated
to the listener that has sent the group response. The received group
response is then decrypted and its authenticity is verified. More
details about how group responses are processed in the multicast
group are provided in Section 6.
Tiloca Expires April 16, 2016 [Page 12]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
+--------+-------------------------------------------------+
| | +--------+------------------------------------+ |
| | | | +-------------+------------------+ | |
| | | | | | +--------------+ | | |
| IP | | UDP | | DTLS Record | | Group | | | |
| header | | header | | Header | | message | | | |
| | | | | | +--------------+ | | |
| | | | +-------------+------------------+ | |
| | +--------+------------------------------------+ |
+--------+-------------------------------------------------+
Figure 2: A message protected using the group DTLS Record Layer
While assuring two-way secure communication within the multicast
group, the approach described in this draft also displays the
following benefits. First, the commonly shared group keying material
makes it possible to avoid the performance of DTLS handshakes
altogether, unless otherwise necessary to establish pairwise secure
sessions among group members. As a consequence, it does not
substantially affect performance of group members (especially if
senders), with further benefits in terms of network readiness and
availability. Second, senders can remain unaware of current and
future listener nodes in the multicast group. Third, listener nodes
are able to securely reply back to sender nodes, without performing a
DTLS handshake first. This is aligned with the guidelines for CoAP
group communication [RFC7252], according to which the endpoint acting
as the CoAP client (i.e. the sender node) SHOULD also act as the DTLS
client (i.e. start the DTLS handshake).
4. Security Data Structures
This section overviews the security data structures referred by the
approach proposed in this draft. In particular, Section 4.1 discusses
the Group Security Association (GSA) owned by all members of the
multicast group. Then, Section 4.2 overviews the security parameter
structure. Finally, Section 4.3 discusses the connection states
referred by senders or listeners in the multicast group.
4.1 Group Security Association
The GSA contains the following elements. Some of them can be not set
or not relevant, as explained below. Every node owns the GSA of each
multicast group where it is a member.
GroupID
SenderID
CipherSuite
client write IV
Tiloca Expires April 16, 2016 [Page 13]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
server write IV
client write encryption key
server write encryption key
client write MAC key
server write MAC key
source_authentication
Member Private Key
{SenderID1, SenderID1 Public Key}
{SenderID2, SenderID2 Public Key}
...
{Listener1 IP address, Listener1 Public Key}
{Listener2 IP address, Listener2 Public Key}
...
a. The GroupID has the same value for all the group members, and
practically represents a short alias for the multicast IP address
associated to the multicast group. In the approach described in
this draft, the GroupID assumes a value in the range between 0 and
255 included.
b. The SenderID value is relevant only for group members configured
(also) as senders, and is provided by the GC upon joining the
group. A SenderID value MUST be unique within the multicast group
at any time, i.e. the multicast group MUST NOT include more than
one member configured (also) as sender and associated to a given
SenderID value. In the approach described in this draft, a
SenderID assumes a value in the range between 0 and 255 included.
The GC provides a list of active sender nodes and their respective
SenderID to all the listener nodes in the multicast group.
c. The GC chooses a CipherSuite which is specified in the GSA of all
the members of the multicast group. If the flag
source_authenticity is set to TRUE, CipherSuite MUST support
source authentication based on public key cryptography. All the
members of the multicast group MUST support the CipherSuite
specified in the GSA.
d. The same group keying material client write IV, server write IV,
client write encryption key, server write encryption key, client
write MAC key and server write MAC key is derived for all members
of the multicast group. To this end, all group members consider
the security parameters master_secret[48], client_random[32] and
server_random[32] in Section 4.2, and rely on the PRF function
defined in Section 6.3 of [RFC5246] to derive the group keying
material. Every listener node, before processing its first group
response message addressed to a given sender node, derives
additional individual keying material and stores it separately
(see Section 6). From then on, the listener node considers this
Tiloca Expires April 16, 2016 [Page 14]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
individual keying material as the client write encryption key and
client write MAC key used when securing outgoing group response
messages addressed to that sender node (see Section 6). That is,
the client write encryption key and client write MAC key in the
GSA on the listener nodes are not affected. When receiving a group
request message from that listener node for the first time, that
sender node derives the same individual keying material in order
to process incoming group response messages from that sender node
(see Section 6), and stores it separately. That is, the client
write encryption key and client write MAC key in the GSA on the
sender nodes are not affected.
e. The source_authentication flag is set to TRUE if it is required to
provide source authentication of all multicast group request
messages sent by all sender nodes and all unicast group response
messages sent by all listener nodes. Conversely, the
source_authentication is set to FALSE if it is required to provide
only group authentication to all multicast group request messages
sent by all sender nodes and all unicast group response messages
sent by all listener nodes.
f. If the source_authentication flag is set to TRUE, every member of
the multicast group stores its own asymmetric private key in the
Member Private Key field. Conversely, if the source_authentication
flag is set to FALSE, the Member Private Key field is neither set
nor relevant on any member of the multicast group.
g. If the source_authentication flag is set to TRUE, every listener
node stores the public key of each sender node in the multicast
group, together with the respective SenderID. In principle,
listener nodes can be provided with the senders' public keys upon
joining the group. As an alternative, a listener node can ask a
trusted Certification Authority for a sender's public key, upon
receiving a multicast group request message from that sender node
for the first time. More details about the retrieval and
verification of senders' public keys are out of the scope of this
draft.
h. If the source_authentication flag is set to TRUE, every sender
node stores the public key of each listener node in the multicast
group, together with the respective IP address. In principle,
sender nodes can ask a trusted Certification Authority for a
listener's public key, upon receiving a unicast group response
message from that listener node for the first time. More details
about the retrieval and verification of senders' public keys are
out of the scope of this draft.
4.2 Security parameter structure
Tiloca Expires April 16, 2016 [Page 15]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
The Group Controller provides the following security parameter
structure to all members of the multicast group, upon their joining.
This structure reflects the definition in [RFC5246], with three
additional fields in order to provide source authentication in the
group, if required.
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
SignatureAlgorithm signature_algorithm;
uint8 signature_key_length;
uint8 signature_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
a. SecurityParameters.entity is set to ConnectionEnd.server for
sender nodes and ConnectionEnd.client for listener nodes.
b. The parameters bulk_cipher_algorithm, cipher_type, enc_key_length,
block_length, fixed_iv_length, record_iv_length, mac_algorithm,
mac_length, mac_key_length, signature_algorithm,
signature_key_length and signature_length are set to the same
value for all the members in the multicast group, based on the
ciphersuite specified in the GSA. In particular, the parameters
signature_algorithm, signature_key_length and signature_length are
set only if the flag source_authentication in the GSA is set to
TRUE. Also, the parameters mac_algorithm, mac_length and
mac_key_length are set only if the flag source_authentication in
the GSA is set to FALSE and the ciphersuite specified in the GSA
supports message authenticity.
c. The parameters prf_algorithm, compression_algorithm,
master_secret[48], client_random[32], and server_random[32] are
set to the same value for all the members in the multicast group.
4.3 Connection states
Tiloca Expires April 16, 2016 [Page 16]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
The group connection states are instantiated on the group members
based on their role(s) in the group, according to the following
rules.
A group member configured as sender instantiates the following
group connection states:
o One write group connection state, instantiated during the sender
node's initialization and referred while sending multicast group
request messages. This group connection state contains an Epoch
value and a Sequence Number value which is incremented for each
DTLS record sent as part of an outgoing multicast group request
message. The first of such DTLS records has 0 as Sequence Number
value.
o One read group connection state for each listener node in the
multicast group. This kind of group connection state is
instantiated upon receiving a unicast group response message from
the associated listener node for the first time. Then, it is
referred when receiving any further unicast group response message
from the associated listener node. This group connection state
contains an Epoch value and a Sequence Number value, which is
updated according to the DTLS anti-replay mechanism, upon
receiving a valid unicast group response message from the
associated listener node. The Sequence Number value is initialized
to 0. Also, the group connection state contains additional
individual keying material related to the associated listener
node, generated and used as described in Section 6.
A group member configured as listener instantiates the following
group connection states:
o One write group connection state for each sender node in the
multicast group, referred while sending unicast group response
messages to the associated sender. This kind of group connection
state is instantiated upon sending a unicast group response
message to the associated sender node for the first time. Then, it
is referred when sending any further unicast group response
message to the associated sender node. This group connection state
contains an Epoch value and a Sequence Number value which is
incremented for each DTLS record sent as part of an outgoing
unicast group response message to the associated sender node. The
first of such DTLS records has 0 as Sequence Number value. Also,
this write group connection state contains additional individual
keying material related to the associated sender node, generated
and used as described in Section 6.
o One read group connection state for each sender node in the
Tiloca Expires April 16, 2016 [Page 17]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
multicast group. This kind of group connection state is
instantiated upon receiving a multicast group request message from
the associated sender node for the first time. Then, it is
referred when receiving any further multicast group request
message from the associated sender node. This group connection
state contains an Epoch value and a Sequence Number value, which
is updated according to the DTLS anti-replay mechanism, upon
receiving a valid multicast group request message from the
associated sender node. The Sequence Number value is initialized
to 0.
5. Secure multicast messages
This section describes the adaptation of the DTLS Record layer to
enable multiple sender nodes in the group to securely send multicast
group request messages.
+---------+---------+--------+--------+------------+--------+
| 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte |
+---------+---------+--------+--------+------------+--------+
| Content | Version | Epoch | Sender | Trunc_seq_ | Length |
| Type | Ma | Mi | | ID | number | |
+---------+---------+--------+--------+------------+--------+
Figure 3: Adapted DTLS record header for multicast group requests
Figure 3 shows the adapted DTLS record layer header, used when a
sender node transmits a multicast group request message. The existing
DTLS record layer header is adapted in such a way that the 6-octet
Sequence_number field is split into a 1-octet SenderID field and a 5-
octet "truncated" Trunc_seq_number field. The epoch is fixed and
provided to the group members by the GC upon joining the multicast
group. The Trunc_seq_number is initialized to 0 and is increased by
one each time the sender node sends a new DTLS record, as part of a
multicast group request message. The group request message is secured
by the source sender node as described in Section 5.2, and processed
by the recipient listener nodes as described in Section 5.3.
5.1 On truncating the sequence number field
The rationale for having the Trunc_seq_number field together with the
SenderID field is as follows.
In the presence of multiple sender nodes in the multicast group, the
sequence number values used by sender nodes need to be synchronized
to avoid their reuse. Otherwise, multicast group request messages
sent by different sender nodes may get discarded as replayed messages
by the recipient listener nodes. Moreover, since all the sender nodes
refer to the same group keying material, this would also result in
Tiloca Expires April 16, 2016 [Page 18]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
nonce reuse in AEAD cipher suites like AES-CCM [RFC6655] and AES-GCM
[RFC5288]. In particular, nonce reuse can completely break the
security of these cipher suites. In fact, according to the AES-CCM
specification for TLS [RFC6655], the CCMNonce is a combination of a
salt value and the message sequence number, that is
struct {
opaque salt[4];
opaque nonce_explicit[8];
} CCMNonce;
More in detail, the salt is the "client write IV" (when the client is
sending) or the "server write IV" (when the server is sending).
Besides, [RFC6655] states that the value of the nonce_explicit MUST
be distinct for each distinct invocation of the CCM encrypt function
for any fixed key. When the nonce_explicit is equal to the sequence
number of the TLS packets, the CCMNonce has the following structure.
struct {
uint32 client_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number
} CCMClientNonce;
struct {
uint32 server_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number
} CCMServerNonce;
In DTLS, the 64-bit sequence number is composed of the 16-bit epoch
value concatenated with the 48-bit sequence number value included in
the DTLS record header. Therefore, in order to prevent that the
CCMNonce is reused, either all the sender nodes in the multicast
group are synchronized with each other, or separate non-overlapping
sequence number spaces have to be created for each sender node.
Synchronization between sender nodes is particularly difficult to
achieve, especially among constrained devices and in LLNs. Therefore,
this draft considers the second approach and separates the sequence
number spaces by embedding a unique sender identifier, namely
SenderID, in the sequence number, as suggested in [RFC5288]. It
follows that the GC is also required to assign a unique SenderID to
each device in the multicast group which is configured as sender. The
GC provides a list of active sender nodes and their SenderID to all
listener nodes in the multicast group.
5.2 Sending secure group request messages
In order to send a DTLS record as part of a secure multicast group
request message, a sender node proceeds as follows.
Tiloca Expires April 16, 2016 [Page 19]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
1. The sender node determines the right GSA and write group
connection state, based on the multicast IP destination address
and destination port number.
2. The sender node includes its own SenderID in the SenderID field of
the adapted header of the DTLS record.
3. The sender node considers the epoch and truncated sequence number
values from the write group connection state. These values are
used to fill the Epoch and Trunc_seq_number fields of the adapted
header of the DTLS record. The first record sent to the multicast
group has truncated sequence number 0.
4. The sender node processes the DTLS record according to the
CipherSuite specified in the GSA. In particular, if the
source_authentication flag in the GSA is set to TRUE, the DTLS
record is signed using the sender's private key, and the signature
is appended to the DTLS record payload. Otherwise, if the
CipherSuite provides only group authentication, the server write
MAC key and server write IV stored in the GSA are used to
authenticate the DTLS record. Finally, if the CipherSuite provides
confidentiality, the server write encryption key and server write
IV stored in the GSA are used to encrypt the DTLS record.
5. The sender node passes the DTLS record down to UDP and IP layers
for transmission on the multicast IP destination address and port
number associated to the multicast group.
6. The sender node updates the truncated sequence number in its own
write group connection state, incrementing its value by 1.
5.3 Receiving secure group request messages
Upon receiving a DTLS record as part of a secure multicast group
request message, a listener node proceeds as follows.
1. The listener node determines the right GSA, based on the multicast
IP destination address and destination port number.
2. The listener node considers the multicast IP destination address
and destination port number as well as the SenderID specified in
the adapted header of the DTLS record, in order to determine the
right read group connection state. This is different from the
standard DTLS logic, according to which the current "client read"
connection state is bound to the IP source address and port
number. If this is the first group request message ever received
from that sender node in the multicast group, the listener node
instantiates a read group connection state associated to that
Tiloca Expires April 16, 2016 [Page 20]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
sender node.
3. The listener node checks the freshness of the received DTLS
record, comparing the values conveyed in the Epoch and
Trunc_seq_number fields with the values of the epoch and truncated
sequence number stored in the selected read group connection
state. The listener node MUST ensure that the retrieved epoch
value coincides with the stored value, and that the retrieved
truncated sequence number value coincides with the stored value.
Otherwise, the DTLS record SHOULD be discarded. Alternatively, a
mechanism based on a sliding window MAY be adopted to accept
genuine out-of-order DTLS records.
4. The listener node processes the DTLS record according to the
CipherSuite specified in the GSA. If the CipherSuite provides
confidentiality, the server write encryption key and server write
IV stored in the GSA are used to decrypt the DTLS record. Then, if
the source_authentication flag in the GSA is set to TRUE, the
listener node checks the authenticity of the DTLS record using the
sender's public key, identified by means of the SenderID conveyed
in the record header. Otherwise, if the CipherSuite provides only
group authentication, the server write MAC key and server write IV
stored in the GSA are used to check the authenticity of the DTLS
record.
5. Once the freshness and authenticity of the DTLS record have been
verified, the listener node passes the DTLS record to the higher
level protocols.
6. The listener node updates the value of the truncated sequence
number in the selected read group connection state.
6. Secure unicast responses to multicast messages
This section describes the adaptation of the DTLS Record layer to
enable listener nodes in the multicast group to securely send unicast
group response messages, as a reply to a multicast group request
message received from a sender node. Unless otherwise necessary to
fulfill further application requirements, the listener nodes are not
required to perform any DTLS handshake with other members of the
multicast group.
Figure 4 shows the adapted DTLS record layer header, used when a
listener node transmits a unicast group response message. The
existing DTLS record layer header is adapted in such a way that the
6-octet Sequence_number field is split into a 1-octet GroupID field
and a 5-octet "truncated" Trunc_seq_number field. The epoch is fixed
and provided to the group members by the GC upon joining the
Tiloca Expires April 16, 2016 [Page 21]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
multicast group. The Trunc_seq_number is initialized to 0 and is
increased by one each time the listener node sends a new DTLS record,
as part of a unicast group response message addressed to the same
sender node.
+---------+---------+--------+--------+------------+--------+
| 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte |
+---------+---------+--------+--------+------------+--------+
| Content | Version | Epoch | Group | Trunc_seq_ | Length |
| Type | Ma | Mi | | ID | number | |
+---------+---------+--------+--------+------------+--------+
Figure 4: Adapted DTLS record header for unicast group responses
The rationale for having the Trunc_seq_number field together with the
GroupID field is as follows. The GroupID field allows a sender node
to correctly "interpret" a unicast group response message as a reply
to a multicast group request message that it has previously sent to
that multicast group. Practically, the GroupID field allows a sender
node to correctly determine the correct GSA to be considered. Also,
together with the IP source address of a unicast group response
message, the GroupID field allows a sender node to correctly
determine the correct read group connection state to be considered,
i.e. the one referred to the correct listener node. The case where a
sender node is configured as sender in different multicast groups
having the same GroupID is discussed in Section 9.6.
Potentially, the same issues discussed in Section 5.1 about the reuse
of nonce values can arise. In fact, all listener nodes in the
multicast group refer to the same GroupID, and it is possible that
their truncated sequence number values become synchronized with each
other. In order to preserve secure communication within the multicast
group, listener nodes derive additional individual keying material
which is used to process outgoing unicast group response messages.
The same individual keying material is derived by sender nodes and
used to process incoming unicast group response messages. This is
described in detail in Section 6.1, while further related security
considerations are provided in Sections 9.2 and 9.3. Group response
messages are secured by a source listener node as described in
Section 6.2, and processed by the recipient sender node as described
in Section 6.3.
6.1 Derivation of listener individual keying material
Before sending its first unicast group response message to a given
sender node in the multicast group, a listener node computes
additional individual keying material, and stores it in the write
group connection state associated to that sender node and the same
group's communication, as detailed below. From then on, the listener
Tiloca Expires April 16, 2016 [Page 22]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
node considers that individual keying material to process all its
outgoing unicast group response messages addressed to that specific
recipient sender node.
Similarly, upon receiving the first group response message from that
listener node in the multicast group, the sender node computes the
same individual keying material, and stores it in the read group
connection state associated to that listener node and the same
group's communication. From then on, the sender node considers that
individual keying material to process all the incoming unicast group
response messages received from that listener node and related to
that group's communication.
The individual keying material is computed according to the same data
expansion scheme referred by DTLS and described in Section 6.3 of
[RFC5246]. The invoked procedure considers as input the client write
key and server write key originally stored in the GSA, the IP address
associated to the listener node, and the SenderID associated to the
sender node. In particular, the following procedure is performed
key_block = PRF(client write key + server write key,
"key derivation",
listener IP address + SenderID);
until enough output has been generated. Specifically, the procedure
stops when an amount of bytes equal to
SecurityParameters.mac_key_length plus
SecurityParameters.enc_key_length has been generated. Then, the
individual keying material is extracted as follows.
The first SecurityParameters.mac_key_length bytes of the key_block
output are considered as the client write MAC key to be used for
unicast responses sent by that listener node to that sender node.
That is, the listener node stores it as the individual client write
MAC key in the write group connection state associated to that sender
node and the same group's communication. Instead, the sender node
stores it as the individual client write MAC key in the read group
connection state associated to that listener node and the same
group's communication.
Then, the following SecurityParameters.enc_key_length of the
key_block output are considered as the client write encryption key to
be used for unicast responses sent by that listener node to that
sender node. That is, the listener node stores it as the individual
client write encryption key in the write group connection state
associated to that sender node and the same group's communication.
Instead, the sender node stores it as the individual client write
encryption key in the read group connection state associated to that
Tiloca Expires April 16, 2016 [Page 23]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
listener node and the same group's communication.
6.2 Sending secure group response messages
In order to send a DTLS record as part of a secure unicast group
response message, a listener node proceeds as follows. If it has
previously established a traditional unicast DTLS session with the
sender node to be replied to, the listener node MUST refer to that
DTLS session to securely reply to the sender node. In such a case,
the listener node is not required to maintain a write group
connection state associated to that sender node and that group's
communication. Otherwise, the listener node performs the following
steps.
1. The listener node determines the right GSA, based on the multicast
IP destination address and destination port number of the
multicast group request message it has received and wants to reply
to.
2. If this is its first group response message ever sent to that
sender node in the multicast group, the listener node instantiates
a write group connection state associated to that sender node.
Then, the listener node derives the necessary individual keying
material and stores it in the write group connection state, as
described in Section 6.1. Otherwise, the listener node determines
the right write group connection state based on the unicast IP
destination address and destination port number of the sender node
to be replied to. The IP destination address is the one previously
retrieved as IP source address from the multicast group request
message. The destination port number is the one previously
retrieved as source port number from the multicast group request
message.
3. The listener node retrieves the GroupID from the GSA and includes
it in the GroupID field of the adapted header of the DTLS record.
4. The listener node considers the epoch and truncated sequence
number values from the selected write group connection state.
These values are used to fill the Epoch and Trunc_seq_number
fields of the adapted header of the DTLS record. The first record
sent to the recipient sender node has truncated sequence number 0.
5. The listener node processes the DTLS record according to the
CipherSuite specified in the GSA. In particular, if the
source_authentication flag in the GSA is set to TRUE, the DTLS
record is signed using the listener's private key, and the
signature is appended to the DTLS record payload. Otherwise, if
the CipherSuite provides only group authentication, the individual
Tiloca Expires April 16, 2016 [Page 24]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
client write MAC key stored in the selected write group connection
state and the client write IV stored in the GSA are used in order
to authenticate the DTLS record. Finally, if the CipherSuite
provides confidentiality, the individual client write encryption
key stored in the selected write group connection state and the
client write IV stored in the GSA are used to encrypt the DTLS
record.
6. The listener node passes the DTLS record down to UDP and IP layers
for transmission on the unicast IP destination address and port
number of the sender to be replied to. The IP destination address
is the one previously retrieved as IP source address from the
multicast group request message. The destination port number is
the one previously retrieved as source port number from the
multicast group request message.
7. The listener node updates the truncated sequence number in the
selected write group connection state, incrementing its value by
1.
6.3 Receiving secure group response messages
Upon receiving a DTLS record as part of a secure unicast group
response message, a sender node proceeds as follows. A node in the
multicast group MUST consider invalid and discard any received group
response message, in case it is not configured as sender node.
1. The sender node checks if a unicast DTLS session has been
previously opened with the source listener node, based on the IP
source address and port number of the received group response
message. In case of positive match, the sender node MUST process
the received message according to the traditional DTLS protocol
[RFC6347]. Note that, in such a case, the sender node is not
required to maintain a read group connection state associated to
that listener node and that group's communication. Conversely, in
case of negative match, the sender node does not yet consider the
received message to be invalid, and moves to step 2.
2. The sender node parses the DTLS record header according to the
format shown in Figure 4, and determines the right GSA, based on
the retrieved GroupID. In case the sender node is configured as
sender in different multicast subgroups having the same GroupID,
the right GSA can be determined as discussed in Section 9.6. If no
GSA associated to that GroupID can be found, the sender node MUST
discard the received message. Otherwise, the sender node moves to
step 3.
3. If this is the first unicast group response message ever received
Tiloca Expires April 16, 2016 [Page 25]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
from that listener node in the multicast group, the sender node
instantiates a read group connection state associated to that
listener node. Then, the sender node derives the necessary
individual keying material and stores it in that read group
connection state, as described in Section 6.1. Otherwise, the
sender node considers the retrieved GroupID and the IP source
address of the listener node, in order to determine the right read
group connection state.
4. The sender node checks the freshness of the received DTLS record,
comparing the values conveyed in the Epoch and Trunc_seq_number
fields with the values of the epoch and truncated sequence number
stored in the selected read group connection state. The sender
node MUST ensure that the retrieved epoch value coincides with the
stored value, and that the retrieved truncated sequence number
value coincides with the stored value. Otherwise, the DTLS record
SHOULD be discarded. Alternatively, a mechanism based on a sliding
window MAY be adopted to accept genuine out-of-order DTLS records.
5. The sender node processes the DTLS record according to the
CipherSuite specified in the GSA. If the CipherSuite provides
confidentiality, the sender node decrypts the DTLS record using
the individual client write encryption key stored in the selected
read group connection state and the client write IV stored in the
GSA. Then, if the source_authentication flag in the GSA is set to
TRUE, the sender node checks the authenticity of the DTLS record
using the listener's public key, identified by means of the
listener IP address. Otherwise, if the CipherSuite provides only
group authentication, the sender node checks the authenticity of
the DTLS record using the individual client write MAC key stored
in the selected read group connection state and the client write
IV stored in the GSA.
6. Once the freshness and authenticity of the DTLS record have been
verified, the sender node passes the DTLS record to the higher
level protocols.
7. The sender node updates the value of the truncated sequence number
in the selected read group connection state.
7. Revocation and redistribution of group security material
The approach for secure group communication presented in this draft
SHOULD rely on additional mechanisms aimed at securely distributing,
revoking, and renewing keying material, multicast security policies,
and security parameters used in the group. In addition, the GC is
intended as primarily responsible for providing the GSA to the group
members. The establishment of the GSA will be part of a future IETF
Tiloca Expires April 16, 2016 [Page 26]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
activity dedicated to the design of a generic key management scheme,
preferably based on requirements and recommendations defined in
[RFC3740][RFC4046][RFC4535]. Nevertheless, in this section we suggest
a possible way to renew the group security material (rekeying) and
provide the current GSA to new group members upon their joining. In
particular, we consider the GC to be an additional member of the
multicast group, and to be configured as a sender node.
As specified in [RFC5246], the group keying material included in the
GSA is computed from the Security Parameters master_secret,
client_random and server_random. in particular, the master_secret is
computed by means of a pre_master_secret value, and the Security
Parameters client_random and server_random. Hence, a group keying
material renewal can be practically performed by securely providing
the group members with a new pre_master_secret value. Upon receiving
it, the group members use it to compute the new master_secret to be
stored in the SecurityParameters structure. Finally, they use the new
master_secret to compute the new group keying material to be stored
in the GSA, as well as the individual keying material to be stored in
the write group connection states on the listener nodes and in the
read group connection states on the sender nodes. All the other
Security Parameters and keying material in the GSA remain unchanged.
In order to assure that rekeying messages are actually sent by the
GC, it is required that source authentication is enabled in the
multicast group, i.e. the source_authentication flag in the GSA is
set to TRUE. As an alternative, the GC can determine the random field
of the new pre_master_secret as the next element of a pre-computed
reversed hash chain, an authentication mechanism derived from
Lamport's one-time password [LAMPORT:1981]. The advantage of this
approach is that the most recently released element in the chain can
be efficiently authenticated by computing its hash, and verifying
that the result is equal to the previously released element in the
chain. Therefore, upon creating the multicast group, it is sufficient
that the GC provides all members with the head element of the hash
chain in an authenticated way, e.g. off-line or through a predefined
point-to-point authenticated channel. Then, all other chain elements
can be automatically and efficiently authenticated by group members.
Furthermore, this approach does not require to configure the GC as an
actual member of the group.
What follows is a brief overview of the key management operations
expected on a regular basis (Section 7.1), and upon a new member's
joining (Section 7.2) or a group member's leaving (Section 7.3).
7.1 Periodical rekeying.
The group keying material SHOULD be renewed in a periodical fashion,
Tiloca Expires April 16, 2016 [Page 27]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
in order to discourage an external adversary from breaking the secure
communication in the group through exhaustive key search or traffic
analysis. Periodical rekeying is effective as long as the group has
not been compromised, i.e. no group members are under the adversary's
control. Furthermore, the amount of time between two consecutive
occurrences of periodical rekeying SHOULD be appropriately defined,
taking into account the specific application requirements, and the
expected level of threat the group is exposed to. Obviously, the more
frequently the periodical rekeying is performed, the less the damage
due to possibly compromised group keying material.
Practically, the GC can periodically broadcast a new securely
generated pre_master_secret to group members. For instance, this can
be done by broadcasting a single DTLS multicast message, protected by
means of the current server write parameters in the GSA, as any other
multicast group request message transmitted to the group. Upon
receiving it, all group members rely on the new pre_master_secret to
update the master_secret in the SecurityParameters structure. After
that, all group members can update the group security material stored
in their GSA, as well as the individual keying material stored in the
write group connection states on the listener nodes and in the read
group connection states on the sender nodes.
7.2 Join rekeying.
Upon a new node joining the group, it is required to assure backward
security, whose importance has been explicitly stressed in [RFC4046].
In particular, the joining node must not be able to access any group
communication which took place before its joining. As a first step,
currently present group members are rekeyed according to the same
procedure described above for periodical rekeying. After that, the GC
provides the updated GSA to the joining node, which can then complete
the join process. The GC is required to provide the joining node with
the GSA through a secure communication channel. As a possible
approach, upon contacting the Resource Directory service to gain
knowledge of the GC address, the joining node could retrieve a public
certificate associated to the GC, use the retrieved public key to
establish a secure channel with the GC, and securely obtain the GSA.
As an alternative, the joining node can establish a DTLS session with
the GC, and receive the GSA as a sequence of protected DTLS records.
7.3 Leave rekeying.
A group member may voluntarily leave the group (i.e. its mission is
concluded or its membership is expired), or it may be forced to leave
(e.g. if it has been found to be compromised or it is suspected so).
In such a case, remaining group members have to be securely provided
with updated group keying material, in order to assure forward
Tiloca Expires April 16, 2016 [Page 28]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
security, whose importance has been explicitly stressed in [RFC4046].
Specifically, the leaving node must not be able to access group
communication which takes place after its departure from the group.
At the same time, the leaving node must be prevented from taking part
in the rekeying process itself, i.e. from accessing the new security
material during its distribution. Since the leaving node is aware of
the current group keying material, the latter can not be used to
securely distribute a new pre_master_secret to the remaining nodes.
As a first easy approach, the GC can establish a different pairwise
symmetric key with every member of the group upon their joining.
Then, upon a node's leaving, the GC could rely on such pairwise keys
to distribute a new pre_master_secret to all the remaining nodes, in
a one-to-one fashion. However, such a unicast approach lacks of
efficiency, as it requires a number of rekeying messages which
linearly grows with the number of nodes in the group, hence not
scaling well with the group size. As an alternative, it is possible
to rely on specific application level schemes for group key
management, which result to be more efficient and display high
scalability with the number of nodes in the group.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
This document describes an adaptation of DTLS 1.2 to support
multicast group communication; therefore, most of the security
considerations are the same as those of DTLS 1.2 [RFC6347] and TLS
1.2 [RFC5246] described in Appendices D, E, and F. Besides, security
issues specifically related to the revocation and redistribution of
security material are discussed in Section 7. Further security issues
to be taken into consideration are discussed below.
9.1 Group-level security
The approach described in this draft relies on commonly shared group
security material to protect communication within the group. Unless
source authentication is adopted, this requires that all group
members are trusted, e.g. they do not forge messages in order to make
them appear as sent by a different member of the group. In many use
case, the devices in a multicast group belong to a common authority
and are configured by a commissioner. For instance, in a professional
lighting scenario, the roles of the sender and listener nodes are
configured by the lighting commissioner, and devices follow those
roles. In case group members can not be trusted to this extent, it is
possible to provide source authenticity through digital signature, as
described in Sections 5 and 6.
Tiloca Expires April 16, 2016 [Page 29]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
Furthermore, encryption and authentication operations rely on a nonce
value in order to randomize the process. With reference to a listener
node which secures a unicast response message, it composes the nonce
as the sequence of i) the client write IV from the GSA; and ii) the
concatenation of epoch, GroupID, and Trunc_seq_number, namely
explicit nonce, that are going to be included in the response DTLS
header. On one hand, the client write IV and the GroupID are the same
for all the listeners in the group. On the other hand, it is possible
that multiple listeners are synchronized with each other as to the
epoch and Trunc_seq_number they use to reply to a given multicast
message from a sender node. In this case, all such listeners consider
the same explicit nonce. Sections 9.2 and 9.3 discuss that reuse of
explicit nonce does not represent a problem, since individual
security material associated to listener nodes is derived on the
listener and sender side.
Finally, the presented approach SHOULD take into consideration the
risk of compromise of group members. As a first thing, the risk of
compromise is reduced when multicast groups are deployed in
physically secured locations, like lighting inside office buildings.
Secondly, the adoption of key management schemes for secure
revocation and renewal of group security material SHOULD be
considered, as discussed in Section 7.
9.2 Prevention of attacks based on IP spoofing
The approach described in this draft makes it possible that all the
listener nodes in the multicast group use different individual pairs
<client write encryption key, client write MAC key> (see Section 6).
It follows that, when securing a unicast group response message, two
listener nodes that rely on the same explicit nonce actually use
different keying material and hence produce two different secured
group response messages. This makes it possible to prevent an active
attack when an external adversary injects fake group response
messages by spoofing the IP source address of a given listener node.
Furthermore, every listener node derives an individual pair <client
write encryption key, client write MAC key> separately for each
sender node in the group (see Section 6.1). This makes it possible to
prevent an active attack when an external adversary intercepts a
unicast group response message sent to a given sender node, and then
replays it to a different sender node by spoofing the IP destination
address.
9.3 Nonce reuse in authenticated encryption
DTLS makes it possible to use Authenticated Encryption with
Tiloca Expires April 16, 2016 [Page 30]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
Associated Data (AEAD) ciphers, such as AES_CCM [RFC6655] or AES_GCM
[RFC5288]. These ciphers require only one key to be used to secure a
message, i.e. listeners would rely only on the client write
encryption key, without using the client write MAC key.
In this case, the possible reuse of the same explicit nonce by
different listener nodes discussed in Section 9.1 is not a problem,
thanks to the derivation of different individual client write
encryption keys for each listener node (see Section 6). This has two
major consequences. First, it makes it possible to still comply with
the requirement of [RFC6655] and [RFC5288], according to which each
value of the explicit nonce MUST be distinct for each distinct
invocation of the encrypt function for any fixed key. Second, it
prevents an adversary from solving underlying keyed hash so making
subsequent forgeries trivial, and from choosing IVs to produce
colliding counters. It follows that any degradation of the provided
security level due to a possible nonce reuse is prevented.
9.4 Late joining nodes
Upon joining the multicast group when the system is fully operative,
listener nodes are not aware of the current epoch and
Trunc_seq_number being used by different sender nodes. This means
that, when such listener nodes receive a multicast message from a
sender node, they are not able to verify if the message is fresh and
has not been replayed by an adversary. In order to address this
issue, we can rely on techniques similar to AERO [I-D.mcgrew-aero],
i.e., upon receiving the first message from a particular sender node,
late joining listener nodes initialize their last seen epoch and
Trunc_seq_number in their read group connection state associated to
that sender node. However, after that they drop such a message,
without delivering it to the application layer. This provides a
reference point to identify if future messages are fresher than the
last one seen. As an alternative, the GC can be an additional member
of the multicast group and be configured as a listener node. Then, it
can maintain the epoch and Trunc_seq_number of each sender node in
the multicast group. When late joiners send a request to the GC to
join the multicast group, the GC can provide them with the list of
epoch and Trunc_seq_number values to be stored in the read group
connection states associated to the appropriate senders.
9.5 Uniqueness of SenderIDs
As discussed in Section 5, it is important that SenderIDs are unique
within a multicast group, in order to preserve the security
properties of the DTLS record layer messages, especially the
freshness of nonce values. Hence, in case two or more sender nodes
are configured with the same SenderID, it becomes necessary to
Tiloca Expires April 16, 2016 [Page 31]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
explicitly avoid the related security weakness and prevent nonce
reuse. To this end, a possible mechanism consists in all sender nodes
in the multicast group acting also as listener nodes. This allows a
sender node S1 that receives a message with the same SenderID in the
DTLS header from a different sender node S2 to become aware of the
SenderID conflict. Then, S1 can notify the GC about the SenderID
conflict through a secure channel. The GC can then provide a
different SenderID to either one of the two sender nodes or both of
them.
9.6 Same GroupID in different multicast groups
In general, every multicast group is managed by a different GC, which
is responsible to determine the associated GroupID to be used within
the group. Then, it is possible that a node is configured as sender
in different multicast groups at the same time, and such multicast
groups are identified by the same, ambiguous, GroupID value. In such
a case, upon receiving a unicast group response message as a reply to
a multicast group request message, such sender nodes would not be
able to determine to which group communication such group response
message refers to, i.e. which GSA and read group connection state has
to be considered to process the received group response message. In
order to overcome this issue, sender nodes can identify the right GSA
and read group connection state to be considered by means of the
extended tuple <GroupID, IP source address, destination port number>
from the DTLS, UDP and IP headers in the group response message. This
relies on the practical assumption that, if a sender node belongs to
different multicast groups at the same time, it actually takes part
in each group's communication through a different application or
application instance, each one of which refers to a different port
number.
9.7 Reduced sequence number space
In the approach described in this draft, the DTLS record layer
sequence_number is truncated from 6 octets to 5 octets. This results
in a reduction of the sequence_number space, which SHOULD be taken
into account to ensure that the epoch value is incremented before the
Trunc_seq_number wraps around. A sender node, or the GC as an
alternative, can send a ChangeCipherSpec message to the whole
multicast group whenever the Trunc_seq_number has been exhausted, in
order that the epoch value is increased by all group members. This
SHOULD be done as part of the key management scheme adopted within
the group, which is out of scope for this draft.
10. References
10.1 Normative References
Tiloca Expires April 16, 2016 [Page 32]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
[I-D.keoh-dice-multicast-security-08]
Keoh, S., Kumar, S., Dijk, E., and A. Rahman, "DTLS-based
Multicast Security in Constrained Environments", draft-
keoh-dice-multicast-security-08 (work in progress), July
2014.
[I-D.kumar-dice-multicast-security-00]
Kumar, S., and R. Struik, "Transport-layer Multicast
Security for Low-Power and Lossy Networks (LLNs)", draft-
kumar-dice-multicast-security-00 (work in progress), March
2015.
[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
Encryption", RFC 5116, January 2008.
[RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008.
[RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6655] Bailey, D., and D. McGrew, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC7252] Shelby Z., Hartke K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
10.2 Informative References
[LAMPORT:1981]
Lamport, L., Password authentication with insecure
communication. Communications of the ACM, 24(11):770-772,
November 1981.
[I-D.mcgrew-aero]
McGrew, D., and J. Foley, "Authenticated Encryption with
Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in
progress), February 2014.
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. van der Stok,
Tiloca Expires April 16, 2016 [Page 33]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
"CoRE Resource Directory", draft-ietf-core-resource-
directory-04 (work in progress), July 2015.
[I-D.vanderstok-core-dna]
Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery,
Naming, and Addressing", draft-vanderstok-core-dna-02
(work in progress), July 2012.
[RFC3740] Hardjono, T., and B. Weis, "The Multicast GroupSecurity
Architecture", RFC 3740, March 2004.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4301] Kent, S., and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
[RFC6282] Hui, J., and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter T., Thubert P., Brandt A., Hui J., Kelsey R., Levis
P., Pister K., Struik R., Vasseur JP., and R. Alexander,
"RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks", RFC 6550, March 2012.
[RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
Tiloca Expires April 16, 2016 [Page 34]
INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7296, October 2014.
[RFC7390] Rahman., A., and E. Dijk, "Group Communication for the
Constrained Application Protocol (CoAP)", RFC 7390,
October 2014.
Authors' Addresses
Marco Tiloca
SICS Swedish ICT AB
Isafjordsgatan 22, 16440 Kista
Sweden
Email: marco@sics.se
Shahid Raza
SICS Swedish ICT AB
Isafjordsgatan 22, 16440 Kista
Sweden
Email: shahid@sics.se
Kirill Nikitin
School of Computer and Communication Sciences, EPFL
EDOC-IC INN 134, Station 14, 1015 Lausanne
Switzerland
Email: kirill.nikitin@epfl.ch
Sandeep S. Kumar
Philips Research
High Tech Campus 34, Eindhoven 5656 AE
The Netherlands
Email: sandeep.kumar@philips.com
Tiloca Expires April 16, 2016 [Page 35]