Internet DRAFT - draft-keoh-dtls-multicast-security
draft-keoh-dtls-multicast-security
DICE S. Keoh
Internet-Draft S.S. Kumar
Intended status: Standards Track O. Garcia-Morchon
Expires: January 7, 2014 E. Dijk
Philips Research
July 6, 2013
DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs)
draft-keoh-dtls-multicast-security-00
Abstract
Wireless IP-based systems will be increasingly used for building
control systems in the future where wireless devices interconnect
with each other, forming low-power and lossy networks (LLNs). The
CoAP/6LoWPAN standards are emerging as the de-facto protocols in this
area for resource-constrained devices. Both multicast and security
are key needs in these networks. This draft presents a method for
securing multicast communication in LLNs based on the DTLS which is
already present in CoAP devices. This draft deals with the
adaptation of the DTLS record layer to protect multicast group
communication, assuming that all member devices already have a group
key in their own possession. The DTLS record layer implementation is
used to encrypt a multicast message and to provide message
authentication using the group key before sending the message via IP
multicast to the group.
Requirements Language
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].
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."
Keoh, et al. Expires January 7, 2014 [Page 1]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
This Internet-Draft will expire on November 18, 2013.
Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 4
2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Security Requirements . . . . . . . . . . . . . . . . . . 5
3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . 7
3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Securing Multicast in LLNs . . . . . . . . . . . . . . . . 8
4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 9
4.1. Sending Secure Multicast Messages . . . . . . . . . . . . 9
4.1.1. One Sender, Multiple Listeners Multicast Group . . . . 10
4.1.2. Multiple Senders, Multiple Listeners Multicast Group . 11
4.2. Receiving Secure Multicast Messages . . . . . . . . . . . 12
4.2.1. One Sender, Multiple Listeners Multicast Group . . . . 12
4.2.2. Multiple Senders, Multiple Listeners Multicast Group . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Keoh, et al. Expires January 7, 2014 [Page 2]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
1. Introduction
There is an increased use of wireless control networks in city
infrastructure, environmental monitoring, industrial automation, 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 Internet of Things (IoT). These connected devices are
equipped with communication capability that enables them to interact
with each other as well as with Internet services at anytime and
anyplace. However, the devices in such wireless control networks are
usually battery-operated or powered by scavenged energy, they have
limited computational resources (low CPU clock, small RAM and flash
storage) and often, the communication bandwidth is limited (e.g.,
IEEE 802.15.4 radio), and also the transmission is unreliable. Hence,
such wireless control networks are also known as Low-power and Lossy
Networks (LLNs).
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 that can be effectively used to
convey messages to a group of devices without requiring the sender to
perform time- and energy-consuming multiple unicast transmissions to
reach group members. For example, in a building control management
system, Heating, Ventilation and Air-Conditioning (HVAC) and lighting
devices can be grouped according to the layout of the building, and
control commands can be issued to a group of devices. Group
communication for LLNs has been made possible using the Constrained
Application Protocol (CoAP) [I-D.ietf-core-coap] based on IP-
multicast.
Currently, CoAP can be protected using Datagram Transport Layer
Security (DTLS) [RFC4347]. However, DTLS is mainly used to secure a
connection between two endpoints and it cannot be used to protect
multicast group communication. We believe that 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, they are not necessarily suitable for LLNs which have
much more limited bandwidth and resources. For example, the MIKEY
Architecture [RFC3830] is mainly designed to facilitate multimedia
distribution, while TESLA [RFC4082] is proposed as a protocol for
broadcast authentication of the source and not for protecting the
confidentiality of multicast messages.
Keoh, et al. Expires January 7, 2014 [Page 3]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
This draft describes an approach to use DTLS as mandated in CoAP to
support multicast security. It assumes that all devices in the group
share a group key, e.g., the group key can be distributed by a
controller in the network through a DTLS unicast secure channel to
each device in the group. This draft focuses on the use of DTLS
record layer to protect multicast messages to be sent to the group,
and thus providing integrity, confidentiality and authenticity to the
IP multicast messages in the LLN.
1.1. Terminology
This specification defines the following terminology:
Controller: The entity that is responsible for creating a multicast
group, adding members, and distributing keying material to members of
the group. It is also responsible for renewing/updating the
multicast group keys. It is not necessarily the sender in the
multicast group.
Sender: The entity that sends multicast messages to the multicast
group.
Listener: The entity that receives multicast messages when listening
to a multicast IP address.
1.2. Outline
This draft is structured as follows: Section 2 motivates the proposed
solution with multicast use cases in LLNs and derives a set of
requirements. Section 3 provides an overview of the DTLS-based
multicast security. In Section 4, we describe the use of DTLS record
layer to encrypt and integrity protect multicast messages assuming
that all devices in the group already have a group key in possession.
Section 5 and Section 6 describe Security and IANA considerations.
2. Use Cases and Requirements
This section defines the use cases for multicast and specifies a set
of security requirements for these use cases.
2.1. Use Cases
As stated in the Group Communication for CoAP Internet Draft
[I-D.ietf-core-groupcomm] in the IETF CoRE WG, multicast is essential
in several application use cases. Consider a building equipped with
6LoWPAN [RFC4944] [RFC6282] IP-connected lighting devices, switches,
and 6LoWPAN border routers; the devices are organized as groups
according to their location in the building, e.g., lighting devices
Keoh, et al. Expires January 7, 2014 [Page 4]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
and switches in a room/floor can be configured as a multicast group,
the switches are then used to control the lighting devices in the
group by sending on/off/dimming commands to 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 subnets in the entire building. The
following lists a few multicast group communication uses cases in a
building management system; a detailed description of each use case
can be found in Group Communication for CoAP Internet Draft
[I-D.ietf-core-groupcomm].
a. Lighting control: enabling synchronous operation of a group of
6LoWPAN 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.
b. Firmware update: firmware of devices in a building or a campus
control application are updated simultaneously, avoiding an
excessive load on the LLN due to unicast firmware updates.
c. Parameter update: settings of devices are updated simultaneously
and efficiently.
d. 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.
2.2. Security Requirements
The Miscellaneous CoAP Group Communication Topics Internet Draft
[I-D.dijk-core-groupcomm-misc] has defined 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 as presented in Section 2.1:
a. Multicast communication topology: We consider both one-to-many
and many-to-many communication topologies in this draft. The
one-to-many communication topology is the simplest group
communication scenario that would serve the needs of a typical
LLN. For example, in the lighting control use case, the switch
is the only entity that is responsible for sending control
commands to a group of lighting devices. These lighting devices
are actuators that do not issue commands to each other. In other
use cases, a many-to-many multicast communication topology would
be required, in particular multiple sensors and actuators are
part of a multicast group and these sensors will trigger events
Keoh, et al. Expires January 7, 2014 [Page 5]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
to the group in order to notify the interested parties. Devices
in the group could also send commands in order to trigger some
actions on other devices in the group.
b. Establishment of a Group Security Association (GSA) [RFC3740]: A
secure channel must be used to distribute keying material,
multicast security policy and security parameters to members of a
multicast group. A GSA must be established between the
controller (which manages the multicast group and may be a
different device than the sender) and the group members. The
6LoWPAN border router, a device in the 6LoWPAN, or a remote
server outside the 6LoWPAN could play the role of controller for
distributing keying materials. Since the keying material is used
to derive subsequent group keys to protect multicast messages, it
is important that it is encrypted, integrity protected and
authenticated when it is distributed. However, this 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 be started in the future.
c. Multicast security policy: All group members must use the same
ciphersuite to protect the authenticity, integrity and
confidentiality of multicast messages. The ciphersuite can
either be negotiated or set by the controller and then
distributed to the group members. It is generally very complex
and difficult to require all devices to negotiate and agree with
each other on the ciphersuite to be used, it is therefore more
effective that the multicast security policy is set by the
controller.
d. Multicast data group authentication: It is essential to ensure
that a multicast message is originated from a member of the
group. 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 only the sender of the multicast group is sending the
message, and that all other group members are trusted not to
tamper with the multicast message.
e. Multicast data source authentication: Source authenticity is
optional. It can typically be provided using public-key
cryptography in which every multicast message is signed by the
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 [RFC4082] can be deployed, however it requires devices in
the multicast group to have a trusted clock and have the ability
Keoh, et al. Expires January 7, 2014 [Page 6]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
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,
it is advocated that source authenticity is made optional.
f. Multicast data integrity: A group level integrity is required to
ensure that messages have not been tampered with by attackers who
are not members of the multicast group.
g. Multicast data confidentiality: Multicast message should be
encrypted, as some control commands when sent in the clear could
pose privacy risks to the users.
h. Multicast data replay protection: It must not be possible to
replay a multicast message as this would disrupt the operation of
the group communication.
i. Multicast key management: Group keys used to protect the
multicast communication must be renewed periodically. When
members have left the multicast group, the group keys might be
leaked; and when a device is detected to have been compromised,
this also implies that the group keys could have been compromised
too. In these situations, the controller must perform a re-key
protocol to renew the group keys. This work will be addressed as
part of the key management for LLN in the future.
3. Overview of DTLS-based Secure Multicast
The goal of this draft is to secure IP multicast operations as used
in 6LoWPAN networks, by extending the use of the DTLS security
protocol to allow for the use of DTLS record layer to provide
protection to multicast messages, specifically CoAP group
communication. The IETF CoRE WG has selected DTLS [RFC4347] 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 handshake 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.
Keoh, et al. Expires January 7, 2014 [Page 7]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
3.1. IP Multicast
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. In principle, a sender does not require any prior access
procedures or authentication to send a multicast message, a sender
with a valid multicast group key can essentially send a secure
multicast message to the group. A device becomes a listener to a
specific IP multicast group by listening to the associated IP
multicast address. Any device can in principle decide to listen to
any IP multicast address, and can use the associated valid group key
to authenticate and decrypt the multicast messages. This also means
that no prior access procedure is required to be a listener nor do
applications on the other devices know, or get notified, of new
listeners in the LLN.
++++
|. |
--| ++++
++++ / ++|. |
|A |---------| ++++
| | \ ++|B |
++++ \-----| |
Sender ++++
Listeners
Figure 3.1: The roles of nodes in a one-to-many multicast
communication topology
3.2. Securing Multicast in LLNs
A controller in an LLN creates a multicast group. The 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 controller. The controller in the network can be
discovered by the devices using various methods defined in
[I-D.vanderstok-core-dna] such as DNS-SD [I-D.cheshire-dnsext-dns-sd]
and Resource Directory [I-D.shelby-core-resource-directory]. The
controller communicates with individual device to add them to the new
group. Additionally, the controller can distribute a group key to
all the member devices in the group, e.g., by establishing a secure
DTLS channel with each device, which enables the controller to
securely send the group key to the device. As mentioned previously,
a standardized way of performing key management for LLN is out of
scope of this draft, and we assumes that each device in the group has
Keoh, et al. Expires January 7, 2014 [Page 8]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
been configured with a group key.
Senders in the group can encrypt and sign application messages using
the group key. The message is then encapsulated using the DTLS
record layer before it is sent using IP multicast. For example, a
CoAP message addressed to a multicast group is protected using DTLS
record layer and then sent to a multicast group. The listeners when
receiving the message, use the multicast IP address (i.e., Multicast
identifier) to look up the corresponding sender ID to obtain the
group key. The received message is decrypted using the group key,
and the authenticity is verified using the group key too.
4. Multicast Data Security
This section describes the use of DTLS record layer to secure
multicast messages. This assumes that group membership has been
configured by the controller, and all devices in the group has been
configured with a group key. Two ciphersuites have been defined to
secure multicast communication as follows:
Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2}
Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4}
Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide
confidentiality, integrity and authenticity to the multicast messages
where the encryption algorithm is AES [AES], key length is 128-bit,
and the authentication function is CCM [RFC6655] with a Message
Authentication Code (MAC) length of 8 bytes. Similar to RFC4785
[RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when
confidentiality of multicast messages is not required, it only
provides integrity and authenticity protection to the multicast
message. When this ciphersuite is used, the message is not encrypted
but the MAC must be included in which it is computed using a HMAC
[RFC2104] that is based on Secure Hash Function SHA256 [SHA].
Depending on the future needs, other ciphersuites with different
cipher algorithms and MAC length may be supported.
For the optional multicast data source authentication, the sender can
sign the message using public key cryptography and send it as the
multicast message in the DTLS record payload.
4.1. Sending Secure Multicast Messages
All messages addressed to the multicast group must be secured using
the group key. Using the DTLS record layer, multicast messages are
encrypted and protected using a Message Authentication Code (MAC)
according to the chosen ciphersuite. The MAC is appended to the
Keoh, et al. Expires January 7, 2014 [Page 9]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
encrypted message before it is passed down to the lower layer of the
IP protocol stack for transmission to the multicast address.
As described in the previous section, the ciphersuite
MTS_WITH_AES_128_CCM_8 defines that the multicast message must be
encrypted using AES with a 128-bit group key. Since the CCM mode of
operation is used for authenticated encryption, the same group key is
used to compute the MAC. As for the ciphersuite MTS_WITH_NULL_SHA,
the multicast message must not be encrypted, but a MAC must be
computed using the group key.
+--------+-------------------------------------------------+
| | +--------+------------------------------------+ |
| | | | +-------------+------------------+ | |
| | | | | | +--------------+ | | |
| IP | | UDP | | DTLS Record | | multicast | | | |
| header | | header | | Header | | message | | | |
| | | | | | +--------------+ | | |
| | | | +-------------+------------------+ | |
| | +--------+------------------------------------+ |
+--------+-------------------------------------------------+
Figure 4.1: Sending a multicast message protected using DTLS Record
Layer
4.1.1. One Sender, Multiple Listeners Multicast Group
This section describes the use of DTLS record layer to protect a one-
sender, multiple listeners multicast group communication. In this
setting, it is the responsibility of the controller which configures
the group membership to ensure that there is only one sender in a
multicast group in order to ensure the security properties of the
multicast messages.
The following illustrates the structure of the DTLS record layer
header, the epoch and sequence number are used to ensure message
freshness and to detect message replays. As there is only one sender
in the multicast group, the sender is responsible for maintaining and
manipulating the epoch and sequence number when sending multicast
messages. The receivers in the group are "trusted" not to tamper
with these parameters.
+---------+---------+--------+--------+--------+------------+-------+
| 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | |
+---------+---------+--------+--------+--------+------------+-------+
| Content | Version | Epoch | Seq | Length | Ciphertext | MAC |
| Type | Ma | Mi | | Number | | (Enc) | (Enc) |
+---------+---------+--------+--------+--------+------------+-------+
Keoh, et al. Expires January 7, 2014 [Page 10]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
Figure 4.2: The DTLS record layer header and optionally encrypted
payload and MAC
The sequence number is initialized to 0, and it is increased by one
whenever the sender sends a multicast message. This is the standard
behavior of the current DTLS in order to detect message replay. The
sender or the controller can increase the epoch number by sending a
ChangeCipherSpec message whenever the sequence number has been
exhausted, or whenever the ciphersuite has been changed in order to
reset the sequence number. Finally, the multicast message is
protected (encrypted if needed, and authenticated with a MAC) using
the group key.
4.1.2. Multiple Senders, Multiple Listeners Multicast Group
There is a need to support multi-senders in group communication. In
particular, in a lighting network there are multiple presence sensors
that would be assigned the sender role as they are responsible for
multicasting the presence information to the luminaires in the group.
In this section, we outline an approach to enable all senders in the
group to securely send information using a common group key, while
preserving the freshness and integrity of the messages.
In addition to configuring each device in the group with a group key,
the controller can optionally assign a unique device ID (represented
as two octets) to each device which has the sender role in the group.
The list of senders and their corresponding IDs are then distributed
to the group. This is an additional multicast group setup procedure
that should be performed to ensure that each sender in the group can
be uniquely identified by the group members. Alternatively, this
setup procedure can be eliminated by using the device's compressed
IPv6 address as the sender's unique identifier. The 16-bit address
is known to be unique within a 6LoWPAN network.
Each sender in the group uses its own unique ID (either assigned by
the controller or its own compressed IPv6 address), when sending a
multicast message to the group. It also manages its own epoch and
sequence number, hence they do not need to synchronize them with
other senders in the group. The existing DTLS record layer header is
adapted such that the 6-byte sequence number field is split into a
2-byte sender ID and a 4-byte sequence number fields. Figure 4.3
illustrates the adapted DTLS record layer header. The sender must
include its sender ID in the DTLS record layer header and increase
the sequence number. In order to provide authentication to the
message and prevent message replay, the DTLS record layer header and
payload are MAC-ed using the group key. The MAC is appended to the
payload.
Keoh, et al. Expires January 7, 2014 [Page 11]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
+---------+---------+--------+--------+--------+--------+
| 1 Byte | 2 Byte | 2 Byte | 2 Byte | 4 Byte | 2 Byte |
+---------+---------+--------+--------+--------+--------+
| Content | Version | Epoch | Sender | Seq | Length |
| Type | Ma | Mi | | ID | Number | |
+---------+---------+--------+--------+--------+--------+
Figure 4.3: The adapted DTLS record layer header
4.2. Receiving Secure Multicast Messages
Member devices receiving the multicast message, look up the
corresponding group key to decrypt and verify the MAC of the
multicast message. The destination multicast IP address and the
sender ID can be used to locate the crypto session in order to obtain
the group key. The crypto session must also contain the last
received message's epoch and sequence number, enabling the member
devices to detect message replay. Multicast messages received with a
sequence number less than or equal to the value stored in the crypto
session must be dropped. The epoch number in the received message
must also match the epoch number stored in the corresponding crypto
session. As a consequence of this mechanism, a message that arrives
out-of-order (i.e. with a sequence number less than the value stored
in the crypto session) will be ignored.
4.2.1. One Sender, Multiple Listeners Multicast Group
When a listener receives a protected multicast message from the
sender, it looks up the corresponding group key based on the
multicast IP destination of the packet. This is fundamentally
different from standard DTLS logic in that the group key is bound to
the source IP address. However, given that this is a one sender-
multiple listeners communication topology, it is then possible to
bind the group key to the source IP address, therefore a lookup based
on the source IP address is also possible in this case.
The listeners decrypt and authenticate the multicast message using
the respective group key. The verification of MAC ensures that the
payload and the DTLS Record Layer header have not been tampered with.
As there is only one sender, and all other group members are
"trusted", only the sender is able to manipulate the epoch and the
sequence number, hence once the DTLS header has been authenticated,
the epoch and the sequence number can be sufficiently trusted to
detect any message replay.
Keoh, et al. Expires January 7, 2014 [Page 12]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
4.2.2. Multiple Senders, Multiple Listeners Multicast Group
The listeners in a multi-senders multicast group, first perform a
group key lookup by using the multicast IP destination address of the
packet. By knowing the group key, the listeners must check the MAC
of the message. Using the sender's ID, e.g., the compressed 16-bit
IPv6 address, the listeners ensure that it matches the 2-bytes Sender
ID field in the DTLS Record Layer header. This guarantees that no
one has spoofed the IP address, as it is protected with a MAC.
Subsequently, by authenticating the sender ID field, the listeners
retrieve the crypto session which contains the last stored epoch and
sequence number of the sender and check the freshness of the message
received. The listeners must ensure that the epoch and sequence
number in the message received are higher than the ones stored in the
devices, otherwise the message is discarded. As each sender manages
its own epoch and sequence number, receivers are confident that these
values are reliable. Once the authenticity and freshness of the
message have been checked, the listeners use the group key to decrypt
the message. The epoch and the sequence number in the crypto session
are updated as well.
5. IANA Considerations
tbd
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document discusses various design aspects for multicast security
in LLNs. As such this document, in entirety, concerns security.
7. Acknowledgements
The authors greatly acknowledge discussion, comments and feedback
from Dee Denteneer, Peter van der Stok and Zach Shelby. We also
appreciate prototyping and implementation efforts by Pedro Moreno
Sanchez who worked as an intern at Philips Research.
8. References
8.1. Normative References
[AES] National Institute of Standards and Technology, ,
"Specification for the Advanced Encryption Statndard
(AES)", FIPS 197, Nov 2001.
Keoh, et al. Expires January 7, 2014 [Page 13]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012.
[SHA] National Institute of Standards and Technology, , "Secure
Hash Standard", FIPS 180-2, Aug 2002.
8.2. Informative References
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
[I-D.dijk-core-groupcomm-misc]
Dijk, E. and A. Rahman, "Miscellaneous CoAP Group
Communication Topics", draft-dijk-core-groupcomm-misc-03
(work in progress), December 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-16
(work in progress), May 2013.
[I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-07 (work in progress), May 2013.
[I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Out-of-Band Public Key Validation for
Transport Layer Security (TLS)", draft-ietf-tls-oob-
Keoh, et al. Expires January 7, 2014 [Page 14]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
pubkey-07 (work in progress), February 2013.
[I-D.shelby-core-resource-directory]
Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource
Directory", draft-shelby-core-resource-directory-05 (work
in progress), February 2013.
[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.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J.D., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK)
Ciphersuites with NULL Encryption for Transport Layer
Security (TLS)", RFC 4785, January 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
Keoh, et al. Expires January 7, 2014 [Page 15]
Internet-Draft DTLS-based Multicast Security for LLN July 6, 2013
Authors' Addresses
Sye Loong Keoh
Philips Research
High Tech Campus 34
Eindhoven 5656 AE
NL
Email: sye.loong.keoh@philips.com
Sandeep S. Kumar
Philips Research
High Tech Campus 34
Eindhoven 5656 AE
NL
Email: sandeep.kumar@philips.com
Oscar Garcia-Morchon
Philips Research
High Tech Campus 34
Eindhoven 5656 AE
NL
Email: oscar.garcia@philips.com
Esko Dijk
Philips Research
High Tech Campus 34
Eindhoven 5656 AE
NL
Email: esko.dijk@philips.com
Keoh, et al. Expires January 7, 2014 [Page 16]
