One document matched: draft-kumar-dice-multicast-security-00.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 RFC7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7390 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7390.xml">
<!ENTITY I-D.mglt-dice-ipsec-for-application-payload SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mglt-dice-ipsec-for-application-payload.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="std" docName="draft-kumar-dice-multicast-security-00"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="Transport-layer Multicast Security for LLNs">Transport-layer Multicast
Security for Low-Power and Lossy Networks (LLNs)</title>
<author fullname="Sandeep S. Kumar" initials="S.S." surname="Kumar">
<organization>Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<region/>
<code>5656 AE</code>
<country>The Netherlands</country>
</postal>
<email>ietf.author@sandeep-kumar.org</email>
</address>
</author>
<author fullname="Rene Struik" initials="R." surname="Struik">
<organization>Struik Security Consultancy</organization>
<address>
<email>rstruik.ext@gmail.com</email>
</address>
</author>
<date day="09" month="March" year="2015"/>
<area>Security</area>
<workgroup>DICE Working Group</workgroup>
<abstract>
<t>CoAP and 6LoWPAN are fast emerging as the de-facto protocol standards in the area of resource-constrained devices forming Low-power and Lossy Networks (LLNs). Unicast communication in such networks are secured at the transport layer using DTLS, as mandated by CoAP. For various applications, IP multicast-based group communications in such networks provide clear advantages. However, at this point, CoAP does not specify how to secure group communications in an interoperable way.
This draft specifies two methods for securing CoAP-based group communication at the transport layer and targets deployment scenarios that may require group authentication, respectively source authentication. The specification leverages the fact that DTLS is already used as the mechanism of choice to secure unicast communications and allows group communications security to be implemented as an extension of DTLS record layer processing, thereby minimizing incremental implementation cost.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t> There is an
ever growing number of electronic devices, sensors and actuators that
have become wireless and Internet connected, thus creating a trend towards the
Internet-of-Things (IoT). These connected devices are equipped with
communication capability based on CoAP <xref target="RFC7252" /> and 6LoWPAN <xref target="RFC6347" /> standards that enables them to interact with each other
as well as with the wider Internet services. However, the devices in
such wireless 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 lighting control
system, 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 CoAP sent over IP- multicast
<xref target="RFC7390" />.</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 with good time synchronization. <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> An existing IP multicast security protocol could be used after profiling as shown in <xref target="I-D.mglt-dice-ipsec-for-application-payload" />. However since DTLS is already mandated for CoAP unicast, this would require an additional security protocol to be implemented on constrained devices.
This draft describes an alternative transport layer approach by reusing already available functionalities in DTLS. This allows CoAP group communication security to be implemented with minimal additional resources as an extension to the DTLS record layer processing. </t>
<section anchor="term" title="Terminology" toc="default">
<t>This specification uses the following terminology:
<list style="symbols">
<t>Group Controller: Entity responsible for creating a multicast group and establishing security associations among authorized group members. This entity is also
responsible for renewing/updating multicast group keys and related policies.</t>
<t>Sender: Entity that sends data to the multicast 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.</t>
<t>Listener: Entity that receives multicast messages when listening to a multicast IP address.</t>
<t>Security Association (SA): Set of policies and cryptographic keying material that together provide security services to network traffic matching this policy
<xref target="RFC3740" />. Here, a Security Association usually includes 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 specified as part of the SA that is necessary to establish and maintain a cryptographic security association, such as keys, key pairs, and
IVs <xref target="RFC4949" />. </t>
<t>Group authentication: Evidence that a received group message originated from some member of this group. This provides assurances that this message was not tampered with
by an adversary outside this group, but does not pinpoint who precisely in the group originated this message.</t>
<t>Source authentication: Evidence that a received group message originated from a specifically identified group member. This provides assurances that this message was not
tampered with by any other group member or an adversary outside this group.</t>
</list></t>
</section>
<section anchor="outlinr" title="Outline" toc="default">
<t>The remainder of this draft is organized as follows. <xref target="ucreq"/> provides use cases for group communications with LLNs. <xref target="DTLSMulticast"/> provides an overview of transport layer secure multicasting, while <xref target="GroupMultDataSec"/> and <xref target="SourceMultDataSec"/> provide the
detailed specifications for securing multicast messaging providing for group authentication and source authentication, respectively.
</t>
</section>
</section>
<section anchor="ucreq" title="Use Cases" toc="default">
<t>This section introduces some use cases for group communications in LLNs
and identifies a set of security requirements for these use cases.</t>
<section anchor="uc" title="Group Communication Use Cases" toc="default">
<t> "Group Communication for CoAP" <xref target="RFC7390" /> 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
group communication uses cases with detailed descriptions.</t>
<t><list style="letters">
<t>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 physical location in the
building, e.g., lighting devices and switches in a room or corridor 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 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 communications 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.
</t>
<t>Integrated Building control: enabling Building Automation and Control Systems to control multiple heating, ventilation and air-conditioning units to pre-defined presets.</t>
<t>Software and Firmware updates: software and firmware updates often comprise quite a large amount of data and can, thereby, overload an LLN that is otherwise typically used to communicate only small amounts of data infrequently. Multicasting such updated data to a larger group of devices at once, rather than sending this as unicast messages to each individual device in turn, can significantly reduce the network load and may also decrease the overall time latency for propagating this data to all devices. With updates of relatively large amounts of data, securing the individual messages is important, even if the complete update itself is secured as a whole, since checking individual received data piecemeal for tampering avoids that devices store large amounts of partially corrupted data and may detect tampering hereof only after all data has been received.</t>
<t>Parameter and Configuration update: settings of a group of similar devices are
updated simultaneously and efficiently. Parameters could be, for example, network load management or network access controls</t>
<t>Commissioning of LLN systems: querying information about the devices
in the local network and their capabilities, e.g., by a commissioning device.</t>
<t>Emergency broadcast: a particular emergency related information (e.g. natural disaster) is relayed to multiple devices.</t>
</list></t>
</section>
<section anchor="secreq" title="Security Requirements" toc="default">
<t>"Group Communications for CoAP" <xref target="RFC7390"/> 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>Group 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 a simple lighting control use case, a switch would be the only
entity that is responsible for sending control commands to a group
of lighting devices. In more advanced lighting control use cases,
an M-to-N 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>Group-level data confidentiality: Data confidentiality may be required if privacy sensitive data is exchanged in the group. Confidentiality is only required at the group level since any member of the group can decrypt the message.</t>
<t>Group-level authentication and integrity: In certain use cases, it is sufficient to ensure the weaker group-level authentication of group messages. Such cases include M-to-N communication topology where M senders all perform similar roles and where M is of approximately the same size as group size N. Group-level authentication is achieved by a single group key that is
known to all group members and used to provide authenticity to the
group messages (e.g., using a Message Authentication Code,
MAC). </t>
<t>Source-level authentication: Certain use-cases require a stronger source-level authentication of group messages. This is especially needed in M-to-N communication topology, where M is closer to 1.
Source authentication can be provided using public-key cryptography in which
every group message is signed by its sender.
</t>
</list></t>
</section>
</section>
<section anchor="DTLSMulticast"
title="Overview of Transport level Secure Multicast" toc="default">
<t> The IETF CoRE WG
has selected DTLS <xref target="RFC6347" /> as the default must-implement security
protocol for securing CoAP unicast traffic. The goal of this draft is to secure CoAP Group communication with minimal additional overhead on resource-constrained embedded devices. We propose to reuse some of the functionalities of DTLS such that a transport-layer multicast security solution can be implemented by extending the DTLS implementation (that already exists on these devices) with minimal adaptation.
</t>
<t> We first give a general overview of how the transport-layer multicast security can be implemented and then provide two variations: one for group authentication and the other for source authentication. </t>
<section anchor="SetSecMulticast" title="Setting up Group Security Association"
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 in unicast to add them to the new group.
This configuration can be done as unicast CoAP based messages sent over a DTLS secured link.
The CoAP resource on the devices that is used to configure the group <xref target="RFC7390"/>can also be used to configure the devices
with the Group Security Association (GSA)
consisting of keying material, security policies security parameters
and ciphersuites. [Note: The details of the CoAP based configuration needs further elaboration in a new revision.] </t>
</section>
<section anchor="RecordMulticast" title="Group Communication packets"
toc="default">
<t>Senders in the group can authenticate and/or encrypt the
CoAP group messages using the keying material in the GSA. The authenticated and/or encrypted message contains a security header which includes a replay counter. This 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"/>.
</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 | | Security | | multicast | | | |
| header | | header | | Header | | message | | | |
| | | | | | +--------------+ | | |
| | | | +--------------------------------+ | |
| | +---------------------------------------------+ |
+--------+-+---------------------------------------------+-+
]]></artwork>
</figure>
<t>
The listeners when receiving the message, use the multicast IPv6 destination address and
port (i.e., multicast group identifier) to derive the corresponding GSA needed for that
group connection. The received message's
authenticity is verified and/or decrypted using the keying material for that
connection and the security header.</t>
</section>
</section>
<section anchor="GroupMultDataSec" title="Group-level Data Authenticity"
toc="default">
<t>This section describes in detail the group level authenticity mechanism for transport level
secure group messages. We assume that group membership has been
configured by the group controller as described in <xref target="SetSecMulticast"/> , and all member devices in the group
have the GSA. The group-level authentication GSA contains the following elements:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
CipherSuite
server write MAC key
server write encryption key
server write IV
SenderID
]]></artwork>
</figure>
<t>The group controller chooses a CipherSuite for the GSA based on knowledge that all devices in the group support the specific CipherSuite. Based on the CipherSuite selected, one or more of the other elements may be empty. For example, if only using authenticity only ciphersuite, the encryption key and IV is not sent, similarly if an AEAD ciphersuite is used then MAC key is not sent. The SenderID is only sent to devices which are senders in the group</t>
<t>The GSA is used to instantiate the needed elements of the "SecurityParameters" structure (shown below) as defined in <xref target="RFC5246" /> for all devices.</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
]]></artwork>
</figure>
<t><list style="letters">
<t> SecurityParameters.entity is set to ConnectionEnd.server for
senders and ConnectionEnd.client for listeners. </t>
<t> bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, fixed_iv_length, record_iv_length, mac_algorithm, mac_length, and mac_key_length is set based on the ciphersuite present in the GSA.</t>
<t> cipher_type is CipherType.aead (if confidentiality is needed) </t>
<t> enc_key_length, block_length are sent in the GSA. </t>
<t> prf_algorithm, compression_algorithm, master_secret[48], client_random[32], and server_random[32] are not used and therefore not set.</t>
</list></t>
<t>The current read and write states are then instantiated for all group
members based on the keying material in the GSA and according to their roles: </t>
<t><list style="letters">
<t> Listeners (ConnectionEnd.client) directly use "server write" parameters in the GSA for instantiating the current read state. The write state is not instantiated and not used. </t>
<t> Senders (ConnectionEnd.server) first pass each of the "server write" parameters in the GSA through a function output=F(SenderID, input) [Note: F needs to be defined later]. The output is then used for instantiating the current write state. </t>
</list></t>
<t>If a device is both a sender and listener, then the read and write states are both instantiated as above. Additionally each connection state
contains the epoch (set to zero) and sequence number which is incremented for each record sent;
the first record sent has the sequence number 0.</t>
<section anchor="recordadapt" title="Group message format"
toc="default">
<t>To reuse the DTLS implementation for group message processing, the DTLS Records are used to send messages in the group. </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 to transport group-level authenticated messages"
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 same packet structure is used to transport group messages with the Content Type set to ContentType.application_data, the version set to DTLS version 1.2 (mandated by CoAP) which uses the version {254, 253}, epoch is fixed for all devices by the controller and the seq_number based on current connection state. The seq_number is increased by one
whenever the sender sends a new group message in the record. Finally, the
message is protected (encrypted and authenticated with a MAC) using
the session keys in the "server write" parameters.</t>
</section>
<section anchor="recordprocess" title="Group message processing"
toc="default">
<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 DTLS record payload based on the "server write" parameters.
It also manages its own epoch and seq_number in the "server write"
connection state; the first record sent has the seq_number 0. After creating the DTLS record, the seq_number is incremented in the "server write" connection state. The 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 connection. This is
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 Source IP addresses. The keying material is same for all
senders however tracking the epoch and the 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. Then the key is passed through the same F function described above to get specific keys for the particular sender.
The listeners decrypt and check the MAC of the message using this key.
This guarantees that no one without access to the GSA has spoofed the message. Subsequently, the listeners retrieve the "client read" connection state
which contains the last stored epoch and 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
seq_number in the message received is at least equal to
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
seq_number in the corresponding "client read"
connection state are updated as well.</t>
</section>
</section>
</section>
<section anchor="SourceMultDataSec" title="Source-level Data Authenticity"
toc="default">
<t>This section describes in detail the source level authenticity mechanism based on public-key cryptography for transport level
secure group messages. We assume that group membership has been
configured by the group controller as described in <xref target="SetSecMulticast"/> , and all member devices in the group
have the GSA.</t>
<t> The source-level authentication GSA contains the following elements:</t>
<t><list style="letters">
<t> For Senders:
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
CipherSuite
{SenderID, SenderID Private Key}
server write encryption key
server write IV
]]></artwork>
</figure>
</t>
<t> For Listeners:
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
CipherSuite
{SenderID1, SenderID1 Public Key}
{SenderID2, SenderID2 Public Key}
{SenderID3, SenderID3 Public Key}
...
server write encryption key
server write IV
]]></artwork>
</figure>
</t>
</list></t>
<t>The group controller chooses a CipherSuite for the GSA for all devices based on knowledge that all devices in the group support the specific CipherSuite. Based on the CipherSuite selected, one or more of the other elements may be empty. For example, if only authenticity is needed then the encryption key and IV is not sent.</t>
<t>The GSA is used to instantiate the needed elements of the "SecurityParameters" structure (shown below) as defined in <xref target="RFC5246" /> for all devices.</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
]]></artwork>
</figure>
<t><list style="letters">
<t> SecurityParameters.entity is set to ConnectionEnd.server for
senders and ConnectionEnd.client for listeners. </t>
<t> bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, fixed_iv_length, and record_iv_length is set based on the ciphersuite present in the GSA.</t>
<t> mac_algorithm, mac_length, and mac_key_length are set different to DTLS since we use public key algorithms. The mac here therefore is a public-key based signature.</t>
<t> enc_key_length, block_length are sent in the GSA if encryption is needed. </t>
<t> prf_algorithm, compression_algorithm, master_secret[48], client_random[32], and server_random[32] are not used and therefore not set.</t>
</list></t>
<t>The current read and write states are then instantiated for all group
members based on the keying material in the GSA and according to their roles: </t>
<t><list style="letters">
<t> Listeners (ConnectionEnd.client) use the SenderID's public keys for instantiating the current read state for different senders. If confidentiality is needed, the "server write" parameters in the GSA is also added to the current read state. The write state is not instantiated and not used.</t>
<t> Senders (ConnectionEnd.server) use the SenderID private key to instantiate the current write state. If confidentiality is used, first pass each of the "server write" parameters in the GSA through a function output=F(SenderID, input) [Note: F needs to be defined later.]. </t>
</list></t>
<t>If a device is both a sender and listener, then the read and write states are both instantiated as above. Additionally each connection state
contains the epoch (set to zero) and sequence number which is incremented for each record sent;
the first record sent has the sequence number 0.</t>
<section anchor="recordadapt_src" title="Group message format"
toc="default">
<t>To reuse the DTLS implementation for group message processing, the DTLS Records are used to send messages in the group with minor changes. </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="DTLSHeader2" height=""
suppress-title="false"
title="The DTLS record layer header to transport source-level authenticity messages"
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 | Sig- |
| Type | Ma + Mi | | number | | (if enc) | nature|
+---------+----+----+--------+--------+--------+------------+-------+
]]></artwork>
</figure>
<t>The same packet structure is used to transport group messages with the Content Type set to ContentType.application_data, the version set to DTLS version 1.2 (mandated by CoAP) which uses the version {254, 253}, epoch is fixed for all devices by the controller and the seq_number based on current connection state. The seq_number is increased by one
whenever the sender sends a new group message in the record. Finally, the
message is signed using the SenderID private key and added to the signature field. If confidentiality is needed then data is encrypted using
the session keys in the "server write" parameters.</t>
</section>
<section anchor="recordprocess_src" title="Group message processing"
toc="default">
<section anchor="SendMult_src" title="Sending Secure Multicast Messages"
toc="default">
<t>Senders in the multicast group when sending a
CoAP group message from the application, create the DTLS record payload based on the current write connection state, i.e. the data (along with the headers) is signed using the private key and if confidentiality is needed, the server write parameters are used to encrypt the data.
It also manages its own epoch and seq_number in the current write
connection state; the first record sent has the seq_number 0. After creating the DTLS record, the seq_number is incremented in the "server write" connection state. The 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_src" 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 source address, source port, multicast IP destination and destination port of the connection. This is
different from standard DTLS logic in that the current
"client read" connection state is bound only to the source IP address and
source 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 source IP addresses. Each of these connection states contain the public key of the corresponding sender. Further tracking the epoch and the seq_number of the
last received packets needs to be kept different for different
senders.</t>
<t>The listeners first perform a public key lookup by retrieving the "client read" connection state using the source address, source port, multicast IPv6 destination address and port of the packet.
The listeners verifies the signature of the message using this public key.
This guarantees that no one without access to the GSA for the specific device has spoofed the message. Subsequently, the listeners retrieve from the "client read" connection state
the last stored epoch and 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
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
the seq_number in the corresponding "client read"
connection state are updated as well.</t>
</section>
</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 seq_number being used by different
senders. When they receive a packet from a sender with a random
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, the
group controller which can act as a listener in the multicast group can
maintain the epoch and 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 seq_numbers to the late joiner. </t>
</section>
</section>
<section anchor="Ack" title="Acknowledgements" toc="default">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC5116;
&RFC5246;
&RFC5288;
&RFC6347;
&RFC6655;
&RFC7252;
&RFC7390;
</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.mglt-dice-ipsec-for-application-payload;
&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-24 01:06:15 |