One document matched: draft-keoh-dice-multicast-security-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5116 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
<!ENTITY RFC5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5288 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5288.xml">
<!ENTITY RFC6347 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6655 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6655.xml">
<!ENTITY RFC2104 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY RFC3740 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3740.xml">
<!ENTITY RFC3830 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml">
<!ENTITY RFC4046 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4046.xml">
<!ENTITY RFC4082 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4082.xml">
<!ENTITY RFC4535 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4535.xml">
<!ENTITY RFC4785 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4785.xml">
<!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC4949 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5374 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5374.xml">
<!ENTITY RFC6282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC6763 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY I-D.dijk-core-groupcomm-misc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dijk-core-groupcomm-misc.xml">
<!ENTITY I-D.ietf-core-groupcomm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-groupcomm.xml">
<!ENTITY I-D.mcgrew-aero SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mcgrew-aero.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.xml">
<!ENTITY I-D.vanderstok-core-dna SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vanderstok-core-dna.xml">
<!ENTITY FIPS.197.2001 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.197.2001.xml">
<!ENTITY FIPS.180-2.2002 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-2.2002.xml">
]>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-keoh-dice-multicast-security-02"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="DTLS-based Multicast Security for LLN">DTLS-based Multicast
Security for Low-Power and Lossy Networks (LLNs)</title>
<author fullname="Sye Loong Keoh" initials="S." surname="Keoh">
<organization>University of Glasgow Singapore</organization>
<address>
<postal>
<street>Republic PolyTechnic, 9 Woodlands Ave 9</street>
<city>Singapore</city>
<region/>
<code>838964</code>
<country>SG</country>
</postal>
<email>SyeLoong.Keoh@glasgow.ac.uk</email>
</address>
</author>
<author fullname="Sandeep S. Kumar" initials="S.S." surname="Kumar" role="editor">
<organization>Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<region/>
<code>5656 AE</code>
<country>NL</country>
</postal>
<email>sandeep.kumar@philips.com</email>
</address>
</author>
<author fullname="Oscar Garcia-Morchon" initials="O."
surname="Garcia-Morchon">
<organization>Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<region/>
<code>5656 AE</code>
<country>NL</country>
</postal>
<email>oscar.garcia@philips.com</email>
</address>
</author>
<author fullname="Esko Dijk" initials="E." surname="Dijk">
<organization>Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<region/>
<code>5656 AE</code>
<country>NL</country>
</postal>
<email>esko.dijk@philips.com</email>
</address>
</author>
<date day="17" month="January" year="2014"/>
<area>Security</area>
<workgroup>DICE Working Group</workgroup>
<abstract>
<t>The CoAP and 6LoWPAN standards are fast emerging as the de-facto
protocols in the area of resource-constrained devices. Such IP-based
systems are foreseen to be used for building and lighting control
systems where wireless devices interconnect with each other, forming
low-power and lossy networks (LLNs). Both multicast and its security are
key needs in these networks. This draft presents a method for securing
IPv6 multicast communication in LLNs based on the DTLS which is already
present for unicast in these CoAP devices. This draft deals with the
adaptation of the DTLS record layer to protect multicast group
communication, assuming that all group members already have the group
security association parameters in their possession. The adapted DTLS record
layer provides message confidentiality, integrity and replay protection to group
messages using the group keying material before sending the message via
IPv6 multicast to the group.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t>There is an increased use of wireless control networks in
environmental monitoring, industrial automation, lighting controls and
building management systems. This is mainly driven by the fact that the
independence from physical control wires allows for freedom of
placement, portability and for reducing the cost of installation as less
cable placement and drilling are required. Consequently, there is an
ever growing number of electronic devices, sensors and actuators that
have become Internet connected, thus creating a trend towards the
Internet-of-Things (IoT). These connected devices are equipped with
communication capability that enables them to interact with each other
as well as with the wider Internet services. However, the devices in
such wireless control networks are characterized by power constraints
(as these are usually battery-operated), have limited computational
resources (low CPU clock, small RAM and flash storage) and often, the
communication bandwidth is limited and unreliable (e.g., IEEE 802.15.4
radio). Hence, such wireless control networks are also known as
Low-power and Lossy Networks (LLNs).</t>
<t>In addition to the usual device-to-device unicast communication that
would allow devices to interact with each other, group communication is
an important feature in LLNs. It is more effective in LLNs to convey
messages to a group of devices without requiring the sender to perform
multiple time and energy consuming unicast transmissions to reach each
individual group member. For example, in a building and lighting control
system, the heating, ventilation, air-conditioning and lighting devices
are often grouped according to the layout of the building, and control
commands are issued simultaneously to a group of devices. Group
communication for LLNs is based on the Constrained Application Protocol
(CoAP) <xref target="I-D.ietf-core-coap" /> sent over IP- multicast
<xref target="I-D.ietf-core-groupcomm" />.</t>
<t>Currently, CoAP messages are protected using Datagram Transport Layer
Security (DTLS) <xref target="RFC6347" />. However, DTLS is mainly used to secure a
connection between two endpoints and it cannot be used to protect
multicast group communication. Group communication in LLNs is equally
important and should be secured as it is also vulnerable to the usual
attacks over the air (eavesdropping, tampering, message forgery, replay,
etc). Although there have been a lot of efforts in IETF to standardize
mechanisms to secure multicast communication
<xref target="RFC3830" /> <xref target="RFC4082" /> <xref target="RFC3740" /> <xref target="RFC4046" /> <xref target="RFC4535" />, they are not necessarily
suitable for LLNs which have much more limited bandwidth and resources.
For example, the MIKEY Architecture <xref target="RFC3830" /> is mainly designed to
facilitate multimedia distribution, while TESLA <xref target="RFC4082" /> is proposed as
a protocol for broadcast authentication of the source and not for
protecting the confidentiality of multicast messages. <xref target="RFC3740" /> and <xref target="RFC4046" /> provide reference architectures for multicast security. <xref target="RFC4535" /> describes Group Secure Association Key Management
Protocol (GSAKMP), a security framework for creating and managing cryptographic groups on a network which can be reused for key management in our context with any needed adaptation for LLNs.</t>
<t>This draft describes an approach to use DTLS as mandated in CoAP
unicast to also support multicast security. We will assume that all
devices in the group already have a group security association
parameters based on a key management mechanism which is outside the
scope of this draft. This draft specification only focuses on the adaptation of
DTLS record layer to protect multicast messages to be sent to the group,
and thus providing confidentiality, integrity and replay protection to the
CoAP group messages.</t>
<section anchor="term" title="Terminology" toc="default">
<t>This specification uses the following terminology: <list
style="symbols">
<t>Group Controller: The entity that is responsible for creating a
multicast group and establishing security associations among
authorized group members. It is also responsible for
renewing/updating the multicast group keys.</t>
<t>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 authorized to transmit data to the group. In an M-to-N
multicast group (where M and N are not necessarily the same
value), M group members are authorized to be senders.</t>
<t>Listener: The entity that receives multicast messages when
listening to a multicast IP address.</t>
<t>Security Association (SA): A set of policy and cryptographic
keys that provide security services to network traffic that
matches that policy <xref target="RFC3740" />. A Security Association usually
contains the following attributes: <list style="symbols">
<t>selectors, such as source and destination transport
addresses.</t>
<t>properties, such as identities.</t>
<t>cryptographic policy, such as the algorithms, modes, key
lifetimes, and key lengths used for authentication or
confidentiality.</t>
<t>keying material for authentication, encryption and
signing.</t>
</list></t>
<t>Group Security Association: A bundling of security associations
(SAs) that together define how a group communicates securely.
<xref target="RFC3740" /></t>
<t>Keying material: Data that is specified as part of the SA which is needed to establish and maintain a cryptographic security association, such as keys, key pairs, and
IVs <xref target="RFC4949" />. </t>
</list></t>
</section>
<section anchor="outlinr" title="Outline" toc="default">
<t>This draft is structured as follows: <xref format="default"
pageno="false" target="ucreq"/> motivates the proposed solution with
group communication use cases in LLNs and derives a set of
requirements. <xref format="default" pageno="false"
target="DTLSMulticast"/> provides an overview of the proposed
DTLS-based multicast security assuming that all devices in the group
already have a group security association parameters in their
possession. In <xref format="default" pageno="false"
target="MultDataSec"/>, we describe the details of the adaptation of
DTLS record layer for confidentiality and integrity protection of the
multicast messages. <xref format="default" pageno="false"
target="Sec"/> presents the security considerations.</t>
</section>
</section>
<section anchor="ucreq" title="Use Cases and Requirements" toc="default">
<t>This section defines the use cases for group communication in LLNs
and specifies a set of security requirements for these use cases.</t>
<section anchor="uc" title="Group Communication Use Cases" toc="default">
<t>The "Group Communication for CoAP" draft <xref format="default"
pageno="false" target="I-D.ietf-core-groupcomm"/> provides the
necessary background for multicast based CoAP communication in LLNs
and the interested reader
is encouraged to first read this document to understand the
non-security related details. This document also lists a few multicast
group communication uses cases with detailed descriptions and some are
listed here briefly:</t>
<t><list style="letters">
<t>Lighting control: enabling synchronous operation of a group of
6LoWPAN <xref target="RFC4944" /> <xref target="RFC6282" /> connected lights in a room/floor/building. This ensures
that the light preset of a large group of luminaires are changed
at the same time, hence providing a visual synchronicity of light
effects to the user.</t>
<t>Firmware update: firmware of devices in a building control
system are updated simultaneously, avoiding an excessive load on
the LLN due to unicast firmware updates.</t>
<t>Parameter update: settings of a group of similar devices are
updated simultaneously and efficiently.</t>
<t>Commissioning of above systems: information about the devices
in the local network and their capabilities can be queried and
requested, e.g. by a commissioning device.</t>
</list></t>
<t>Elaborating on one of the main use cases, Lighting control,
consider a building equipped with 6LoWPAN IP-connected lighting
devices, switches, and 6LoWPAN border routers; the devices are
organized in groups according to their physcial location in the
building, e.g., lighting devices and switches in a room/floor can be
configured as a single multicast group. The switches are then used to
control the lighting devices in the group by sending on/off/dimming
commands to all lighting devices in the group. 6LoWPAN border routers
that are connected to an IPv6 network backbone (which is also
multicast enabled) are used to interconnect 6LoWPANs in the building.
Consequently, this would also enable multicast groups to be formed
across different physical subnets in the entire building.</t>
</section>
<section anchor="secreq" title="Security Requirements" toc="default">
<t>The "Miscellaneous CoAP Group Communication Topics" draft <xref
format="default" pageno="false"
target="I-D.dijk-core-groupcomm-misc"/> already defines a set of
security requirements for group communication in LLNs. We re-iterate
and further describe those security requirements in this section with
respect to the use cases:</t>
<t><list style="letters">
<t>Multicast communication topology: We consider both 1-to-N (one
sender with multiple listeners) and M-to-N (multiple senders with
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 example,
in the simple lighting control use case, the switch is the only
entity that is responsible for sending control commands to a group
of lighting devices. In more advanced lighting control use cases,
a N-to-M communication topology would be required, for example if
multiple sensors (presence or day-light) are responsible to
trigger events to a group of lighting devices.</t>
<t>Multicast group size: The security solutions should support the
typical group sizes that "Group Communication for CoAP" draft
<xref format="default" pageno="false"
target="I-D.ietf-core-groupcomm"/> intends to support. Group size
is the combination of the number of Senders and Listeners in a
group with possible overlap (a Sender can also be a Listener but
need not be always). In typical LLN usecases, the number of
Senders (normally the controlling devices) is much smaller than the number of Listeners (the controlled devices). A
security solution that supports 1 to 255 Senders would cover
the group sizes required for most use cases that are relevant for this
document. The number of Listeners can be larger in the range of 2 to 5,000 devices.</t>
<t>Establishment of a Group Security Association (GSA):
A secure mechanism must
be used to distribute keying materials, multicast security
policies and security parameters to members of a multicast group.
A GSA must be established by the group controller (which manages
the multicast group) among the group members. The 6LoWPAN border
router, a device in the 6LoWPAN, or a remote server outside the
6LoWPAN could play the role of the group controller. However, GSA
establishment is out-of-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
<xref target="RFC3740" />, <xref target="RFC4046" /> and <xref target="RFC4535" />.</t>
<t>Multicast data confidentiality: Multicast message should be
encrypted, as some control commands when sent in the clear could
pose privacy risks to the users.</t>
<t>Multicast data replay protection: It must not be possible to
replay a multicast message as this would disrupt the operation of
the group communication.</t>
<t>Multicast data group authentication and integrity: It is
essential to ensure that a multicast message originated from a
member of the group and that messages have not been tampered with
by attackers who are not members. The multicast group key which is
known to all group members is used to provide authenticity to the
multicast messages (e.g., using a Message Authentication Code,
MAC). This assumes that all other group members are trusted not to
tamper with the multicast message.</t>
<t>Multicast data security ciphersuite: All group members must use
the same ciphersuite to protect the authenticity, integrity and
confidentiality of multicast messages. The ciphersuite is part of
the GSA. Typically authenticity is more important than
confidentiality in LLNs. Therefore the proposed multicast data
security protocol must support atleast ciphersuites with MAC only
(NULL encryption) and AEAD <xref target="RFC5116" /> ciphersuites. Other ciphersuites that
are defined for data record security in DTLS should also be
preferably supported.</t>
<t>Multicast data source authentication: Source authenticity is
required if the group members are assumed to be untrusted and can
tamper with the multicast messages. Source authenticity is not a
critical feature to be always enabled in every LLN use case. If
source authenticity is required for a specific use case, then it
can be typically provided using public-key cryptography in which
every multicast message is additionally signed by each sender.
This requires much higher computational resources on both the
sender and the receivers, thus incurring too much overhead and
computational requirements on devices in LLNs. Alternatively, a
lightweight broadcast authentication, i.e., TESLA <xref target="RFC4082" /> can be
deployed, however it requires devices in the multicast group to
have a trusted clock and have the ability to loosely synchronize
their clocks with the sender. Consequently, given that the
targeted devices have limited resources, and the need for source
authenticity is not critical in every use case, source
authenticity is not performed by default as part of the proposed
data security protocol but can be added to it using additional
mechanisms which are specified in this draft. It is important to
note that for use cases demanding source authenticity, additional
security mechanism is needed to provide such guarantee. </t>
<t>Forward security: Devices that leave the group
should not have access to any future GSAs. This ensures
that a past member device cannot continue to decrypt confidential data that is sent in the group. It also ensures that this device cannot send encrypted and/or integrity protected data after it leaves the
group. The GSA update mechanism has to be defined as part of the key management scheme.</t>
<t>Backward confidentiality: A new device joining the
group should not have access to any old GSAs. This
ensures that a new member device cannot decrypt data sent before
it joins the group. The key management scheme should ensure that the GSA is updated to ensure backward confidentality. </t>
</list></t>
</section>
</section>
<section anchor="DTLSMulticast"
title="Overview of DTLS-based Secure Multicast" toc="default">
<t>The goal of this draft is to secure CoAP Group communication over
6LoWPAN networks, by extending the use of the DTLS security protocol to
allow for the use of DTLS record layer with minimal adaptation. The IETF CoRE WG
has selected DTLS <xref target="RFC6347" /> as the default must-implement security
protocol for securing CoAP, therefore it is conceivable that DTLS can be
extended to facilitate CoAP-based group communication. Reusing DTLS for
different purposes while guaranteeing the required security properties
can avoid the need to implement multiple security protocols and this is
especially beneficial when the target deployment consists of
resource-constrained embedded devices. This section first describes
group communication based on IP multicast, and subsequently sketches a
solution for securing group communication using DTLS.</t>
<section anchor="IPMulticast" title="IP Multicast" toc="default">
<t>Devices in the LLN are categorized into two roles, (1) sender and
(2) listener. Any node in the LLN may have one of these roles, or both
roles. The application(s) running on a device basically determine
these roles by the function calls they execute on the IP stack of the
device.</t>
<t>In principle, a sender or listener does not require any prior
access procedures or authentication to send or listen to a multicast
message <xref target="RFC5374" />. 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 by registering with a network routing
device, signaling its intent to receive packets sent to that
particular IPv6 multicast group. <xref format="default" pageno="false"
target="OneManyMulticast"/> depicts a 1-to-N multicast communication
and the roles of the nodes. Any device can in principle decide to
listen to any IPv6 multicast address. This also means applications on
the other devices do not know, or do not get notified, when new
listeners join the LLN. More details on the IPv6 multicast and CoAP
group communication can be found in <xref target="I-D.ietf-core-groupcomm" />. This
draft does not intend to modify any of the underlying group
communication or multicast routing protocols.</t>
<figure align="center" alt="" anchor="OneManyMulticast" height=""
suppress-title="false"
title="The roles of nodes in a 1-to-N multicast communication topology"
width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
++++
|. |
--| ++++
++++ / ++|. |
|A |---------| ++++
| | \ ++|B |
++++ \-----| |
Sender ++++
Listeners
]]></artwork>
</figure>
</section>
<section anchor="SecMulticast" title="Securing Multicast in LLNs"
toc="default">
<t>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
creates a new group over the network. In some cases, devices may be
configured using a commissioning tool that mediates the communication
between the devices and the group controller. The controller in the
network can be discovered by the devices using various methods defined
in <xref target="I-D.vanderstok-core-dna" /> such as DNS-SD <xref target="RFC6763" /> and Resource
Directory <xref target="I-D.ietf-core-resource-directory" />. The group controller
communicates with individual device to add them to the new group.
Additionally it distributes the Group Security Association (GSA)
consisting of keying material, security policies security parameters
and ciphersuites using a standardized key management for LLN which is
out of 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. We provide two examples of
ciphersuites (based on the security requirements) that could be defined as part of a future key management
mechanism:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2}
Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4}
]]></artwork>
</figure>
<t>Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide
confidentiality, integrity and authenticity to the multicast messages
where the encryption algorithm is AES <xref target="FIPS.197.2001" />, key length is 128-bit,
and the authentication function is CCM <xref target="RFC6655" /> with a Message
Authentication Code (MAC) length of 8 octets. Similar to
<xref target="RFC4785" />, the ciphersuite MTS_WITH_NULL_SHA is used when
confidentiality of multicast messages is not required, it only
provides integrity and authenticity protection to the multicast
message. When this ciphersuite is used, the message is not encrypted
but the MAC must be included in which it is computed using a HMAC
<xref target="RFC2104" /> that is based on Secure Hash Function SHA256 <xref target="FIPS.180-2.2002" />.
Depending on the future needs, other ciphersuites with different
cipher algorithms and MAC length may be supported.</t>
<t>Senders in the group can encrypt and authenticate the
CoAP group messages from the application using the keying material into the DTLS record. The authenticated encrypted message is passed down to the lower layer of the IPv6
protocol stack for transmission to the multicast address as depicted
in <xref format="default" pageno="false" target="DTLSPacket"/>.
The listeners when receiving the message, use the multicast IPv6 destination address and
port (i.e., Multicast identifier) to look up the GSA needed for that
group connection. The received message is then decrypted and the
authenticity is verified using the keying material for that
connection.</t>
<figure align="center" alt="" anchor="DTLSPacket" height=""
suppress-title="false"
title="Sending a multicast message protected using DTLS Record Layer"
width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
+--------+-------------------------------------------------+
| | +--------+------------------------------------+ |
| | | | +-------------+------------------+ | |
| | | | | | +--------------+ | | |
| IP | | UDP | | DTLS Record | | multicast | | | |
| header | | header | | Header | | message | | | |
| | | | | | +--------------+ | | |
| | | | +-------------+------------------+ | |
| | +--------+------------------------------------+ |
+--------+-------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="MultDataSec" title="Multicast Data Security"
toc="default">
<t>This section describes in detail the use of DTLS record layer to
secure multicast messages. This assumes that group membership has been
configured by the group controller, and all member devices in the group
have the GSA. </t>
<section anchor="secparam" title="SecurityParameter derivation"
toc="default">
<t>The GSA is used to derive the same "SecurityParameters"
structure as defined in <xref target="RFC5246" /> for all devices.</t>
<t>The SecurityParameters.ConnectionEnd should be set to "server" for
senders and "client" for listeners. The current read and write states
can be derived from SecurityParameters by generating the six keying
materials:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
client write MAC key
server write MAC key
client write encryption key
server write encryption key
client write IV
server write IV
]]></artwork>
</figure>
<t>This requires that the client_random and server_random within the
SecurityParameters are also set to the same value for all devices as
part of the GSA to derive the same keying material for all devices in
the group with the PRF function defined in Section 6.3 of <xref target="RFC5246" /> .
Alternatively, the GSA could directly include the above six keying
material when being configured in all group devices.</t>
<t>The current read and write states are instantiated for all group
members based on the keying material and according to their roles:
senders use "server write" parameters for the write state and listeners use "server write"
parameters for the read state. Additionally each connection state
contains the sequence number which is incremented for each record sent;
the first record sent has the sequence number 0.</t>
</section>
<section anchor="recordadapt" title="Record layer adaptation"
toc="default">
<t>In this section, we describe in detail the adaptation of the DTLS Record layer to enable
multiple senders in the group to securely send information using a
common group key, while preserving the confidentiality, integrity and freshness of
the messages.</t>
<t>The following <xref format="default" pageno="false"
target="DTLSHeader"/> illustrates the structure of the DTLS record
layer header, the epoch and seq_number are used to ensure message
freshness and to detect message replays.</t>
<figure align="center" alt="" anchor="DTLSHeader" height=""
suppress-title="false"
title="The DTLS record layer header and optionally encrypted payload and MAC"
width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
+---------+---------+--------+--------+--------+------------+-------+
| 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | |
+---------+---------+--------+--------+--------+------------+-------+
| Content | Version | epoch | seq_ | Length | Ciphertext | MAC |
| Type | Ma | Mi | | number | | (Enc) | (Enc) |
+---------+---------+--------+--------+--------+------------+-------+
]]></artwork>
</figure>
<t>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 sender sends a new record message. This is the
mechanism of DTLS to detect message replay. Finally, the
message is protected (encrypted and authenticated with a MAC) using
the session keys in the "server write" parameters.</t>
<t>One of the problems with supporting multiple senders is that, the seq_number used by senders need to be syncronized to avoid their reuse, otherwise packets sent by different senders may get discarded as replayed packets. Further, the bigger problem is using a
single key in a multiple sender scenario leads to nonce reuse in AEAD cipher suites
like AES-CCM <xref target="RFC6655" /> and AES-GCM <xref target="RFC5288" /> as defined in DTLS. Nonce reuse can
completely break the security of these cipher suites. </t>
<t>According to the AES-CCM for TLS, Section 3 <xref target="RFC6655" />, the CCMNonce is a
combination of a salt value and the sequence number.</t>
<figure align="left" alt="" height="" suppress-title="false"
title="" width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
struct {
opaque salt[4];
opaque nonce_explicit[8];
} CCMNonce;
]]></artwork>
</figure>
<t>The salt is the "client write IV" (when the client is sending) or
the "server write IV" (when the server is sending) as defined in the
"SecurityParameters". Further <xref target="RFC6655" /> requires 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 structure as below:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="" width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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.
]]></artwork>
</figure>
<t>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 is reused, either all
senders need to synchronize or seperate non-overlapping sequence
number spaces need to be created for each sender. Synchronization
between senders is especially hard in LLN and therefore we go for
the second approach of seperating the sequence number spaces by
embedding a unique sender identifier in the sequence number as
suggested in <xref target="RFC5288" />.</t>
<t>Thus in addition to configuring each device in the group with the
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 1-octet based on the requirement for the supported group size mentioned in <xref target="secreq" />. The list of SenderIDs are then distributed to all the group members by the controller.</t>
<t>The existing DTLS record layer header is adapted such that the
6-octet seq_number field is split into a 1-octet SenderID field
and a 5-octet "truncated" trunc_seq_number field. <xref target="adapDTLSHeader" /> illustrates the adapted DTLS record layer header.</t>
<figure align="center" alt="" anchor="adapDTLSHeader" height=""
suppress-title="false"
title="The adapted DTLS record layer header" width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
+---------+---------+--------+--------+-----------+--------+
| 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte |
+---------+---------+--------+--------+-----------+--------+
| Content | Version | Epoch | Sender | trunc_seq_| Length |
| Type | Ma | Mi | | ID | number | |
+---------+---------+--------+--------+-----------+--------+
]]></artwork>
</figure>
</section>
<section anchor="SendMult" title="Sending Secure Multicast Messages"
toc="default">
<t>Senders in the multicast group when sending a
CoAP group message from the application, create the adapted DTLS record payload based on the "server write" parameters.
Each sender in the group uses its own unique SenderID in the DTLS record layer header.
It also manages its own epoch and trunc_seq_number in the "server write"
connection state; the first record sent has the trunc_seq_number 0. After creating the DTLS record, the trun_seq_number is incremented in the "server write" connection state. The adapted DTLS record is then passed down to UDP and IPv6 layer for transmission on the multicast IPv6 destination address and port.</t>
</section>
<section anchor="RecMult" title="Receiving Secure Multicast Messages"
toc="default">
<t>When a listeners receives a protected multicast message from the
sender, it looks up the corresponding "client read" connection state
based on the multicast IP destination and port of the packet. This is
fundamentally different from standard DTLS logic in that the current
"client read" connection state is bound to the source IP address and
port.</t>
<t>Listener devices in a multiple senders multicast group, need to
store multiple "client read" connection states for the different
senders linked to the SenderIDs. The keying material is same for all
senders however the epoch and the trunc_seq_number of the
last received packets needs to be kept different for different
senders.</t>
<t>The listeners first perform a "server write" keys lookup by
using the multicast IPv6 destination address and port of the packet. By knowing
the keys, the listeners decrypt and check the MAC of the message.
This guarantees that no one has spoofed the SenderID, as it is
protected by the MAC. Subsequently, by authenticating the SenderID
field, the listeners retrieve the "client read" connection state
which contains the last stored epoch and trunc_seq_number
of the sender, which is used to check the freshness of the message
received. The listeners must ensure that the epoch is the same and
trunc_seq_number in the message received is higher than
the stored value, otherwise the message is discarded. Alternatively
a windowing mechanism can be used to accept genuine out-of-order
packets. Once the authenticity and freshness of the message have been checked, the
listeners can pass the message to the higher layer protocols. The
epoch and the trunc_seq_number in the corresponding "client read"
connection state are updated as well.</t>
</section>
</section>
<section anchor="Sec" title="Security Considerations" toc="default">
<t>Some of the security issues that should be taken into consideration
are discussed below.</t>
<section anchor="latejoiner" title="Late joiners" toc="default">
<t>Listeners who are late joiners to a multicast group, do not know
the current epoch and trun_seq_number being used by different
senders. When they receive a packet from a sender with a random
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
overcome this late joiner security issue, we can use the techniques
similar to AERO <xref target="I-D.mcgrew-aero" /> where the late joining listener on
receiving the first packet from a particular sender, initialize its
last seen epoch and trunc_seq_number in the "client read" state for that sender,
however does not pass this packet to the application layer and instead drops it. This provides a reference point to identify if future
packets are fresher than the last seen packet. Alternatively, the
group controller which can act as a listener in the multicast group can
maintain the epoch and trunc_seq_number of each sender. When late
joiners send a request to the group controller to join the multicast
group, the group controller can send the list of epoch and trunc_seq_numbers as part of the GSA. </t>
</section>
<section anchor="uniqueSenderID" title="Uniqueness of SenderIDs" toc="default">
<t> It is important that SenderIDs are unique to maintain the security
properties of the DTLS record layer messages. However in the event
that two or more senders are configured with the same SenderID, a
mechanism needs to be present to avoid a security weakness and
recover from the situation. One such mechanism is that all senders
of the mutlicast group are also listeners. This allows a sender
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 sender can inform the controller on a secure channel
about the clash along with the source IP address. The controller can
then provide a different SenderID to either device or both.</t>
</section>
<section anchor="seqSpace" title="Reduced sequence number space" toc="default">
<t>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 account to ensure that epoch is incremented before the
trunc_seq_number wraps over. The sender or the controller
can increase the epoch number by sending a ChangeCipherSpec message
whenever the trunc_seq_number has been exhausted.
This should be done as part of the key management mechanism
which is not defined in this draft.</t>
</section>
</section>
<section anchor="Ack" title="Acknowledgements" toc="default">
<t>The authors greatly acknowledge discussion, comments and feedback
from Dee Denteneer, Peter van der Stok, Zach Shelby and Michael StJohns. Additionally
thank David McGrew for suggesting options for recovering from a SenderID
clash, and John Foley for the extensive review and pointing us to the
AERO draft. We also appreciate prototyping and implementation efforts by
Pedro Moreno Sanchez who worked as an intern at Philips Research.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC5116;
&RFC5246;
&RFC5288;
&RFC6347;
&RFC6655;
&I-D.ietf-core-coap;
&I-D.ietf-core-groupcomm;
</references>
<references title="Informative References">
&RFC2104;
&RFC3740;
&RFC3830;
&RFC4046;
&RFC4082;
&RFC4535;
&RFC4785;
&RFC4944;
&RFC4949;
&RFC5374;
&RFC6282;
&RFC6763;
&FIPS.197.2001;
&FIPS.180-2.2002;
&I-D.ietf-core-resource-directory;
&I-D.vanderstok-core-dna;
&I-D.dijk-core-groupcomm-misc;
&I-D.mcgrew-aero;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:31:37 |