Internet DRAFT - draft-kumar-dice-groupcomm-security
draft-kumar-dice-groupcomm-security
DICE Working Group S. Kumar
Internet-Draft Philips Research
Intended status: Standards Track July 02, 2014
Expires: January 3, 2015
Group Communication Security for Low-Power and Lossy Networks (LLNs)
draft-kumar-dice-groupcomm-security-00
Abstract
CoAP unicast and group communication for low-power and lossy networks
(LLNs) are foreseen to be used for building and lighting control
systems. Although unicast CoAP communication mandates DTLS for
security, no similar existing security mechanisms exist to secure
CoAP group communication. The draft, DTLS multicast security
[I-D.keoh-dice-multicast-security], proposes a solution based on
reusing the DTLS record layer to also secure CoAP group
communication. Although that solution has advantages in terms of
code reuse, it does not ensure source authentication within the
group. This draft presents alternative CoAP group communication
security solutions based on public key cryptographic signatures to
also ensure source authentication within the group.
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."
This Internet-Draft will expire on January 3, 2015.
Copyright Notice
Copyright (c) 2014 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
Kumar Expires January 3, 2015 [Page 1]
Internet-Draft Group Communication Security for LLN July 2014
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security Requirements . . . . . . . . . . . . . . . . . . . . 4
3. Overview for Secure Group Communication . . . . . . . . . . . 6
3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Abstract model for securing group communication . . . . . 7
3.2.1. Sending Secure Multicast Messages . . . . . . . . . . 8
3.2.2. Receiving Secure Multicast Messages . . . . . . . . . 9
4. Specific solutions for Group Communication Security . . . . . 10
4.1. CoAP based solution . . . . . . . . . . . . . . . . . . . 11
4.2. Shim layer solution . . . . . . . . . . . . . . . . . . . 11
4.3. Comparison between the solutions . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Group level confidentiality . . . . . . . . . . . . . . . 13
6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Uniqueness of Sender IDs . . . . . . . . . . . . . . . . 13
6.4. Sequence number space . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
There is an increased use of wireless control networks in
environmental monitoring, industrial automation, lighting controls
and building management systems. Additionally these connected
devices are equipped with IP 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 characterized as Low-power and Lossy
Kumar Expires January 3, 2015 [Page 2]
Internet-Draft Group Communication Security for LLN July 2014
Networks (LLNs). The Constrained Application Protocol (CoAP)
[I-D.ietf-core-coap] and 6LoWPAN [RFC4944] standards are fast
emerging as key protocols for enabling IP connectivity in LLNs.
In addition to the usual device-to-device unicast communication that
allow devices to directly interact with each other, group
communication is an important feature in these 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. Group
communication for LLNs is based on the CoAP sent over IP- multicast
[I-D.ietf-core-groupcomm].
Currently, unicast CoAP messages are protected using Datagram
Transport Layer Security (DTLS) [RFC6347]. Although 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), there is no
such similar security mechanisms defined.
The DTLS Multicast draft [I-D.keoh-dice-multicast-security] proposes
an approach to reuse DTLS as mandated in CoAP unicast to also support
multicast security. It uses an adaptation of the DTLS record layer
to protect multicast messages to be sent to the group, and thus
providing "group level" confidentiality, integrity and replay
protection to the CoAP group messages.
Although that solution has different advantages like code reuse and
transparency at the CoAP layer, it does not provide source
authentication since all members of the group share a common key.
This draft describes alternative solutions based on public-key
cryptography (PKC) to ensure source authentication within the group
and compare it with [I-D.keoh-dice-multicast-security] solution.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This specification uses the same terminology as in
[I-D.keoh-dice-multicast-security]:
o 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.
Kumar Expires January 3, 2015 [Page 3]
Internet-Draft Group Communication Security for LLN July 2014
o Sender: The Sender is an entity that sends data to the multicast
group. In a 1-to-N multicast group only a single Sender is
transmits 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
Senders.
o Listener: The entity that receives multicast messages when
listening to a specific multicast IP address.
o Security Association (SA): A set of policy and cryptographic keys
that provide security services to network traffic that matches
that policy [RFC3740]. A Security Association usually contains
the following attributes:
* selectors, such as source and destination identifiers.
* cryptographic policy, such as the algorithms, modes, key
lifetimes, and key lengths used for authentication or
confidentiality.
* keying material for authentication, encryption and signing.
o Group Security Association (GSA): A bundling of security
associations (SAs) that together define how a group communicates
securely. [RFC3740]
o 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 [RFC4949].
1.2. Outline
This draft is structured as follows: Section 2 list the security
requirements to be achieved. Section 3 first presents the proposed
group communication security at an abstract level. In Section 4, we
present specific solutions based on the abstract solution, one based
on directly adding security into CoAP and the other using a shim
layer. We also compare these solutions to the the one proposed in
[I-D.keoh-dice-multicast-security]. Section 6 presents the security
considerations.
2. Security Requirements
The "Miscellaneous CoAP Group Communication Topics" draft
[I-D.dijk-core-groupcomm-misc] defines a set of security requirements
for group communication in LLNs. In this section, we re-iterate and
further classify the security requirements into those that are
assumed to be fulfilled and those that need to be fulfilled by the
Kumar Expires January 3, 2015 [Page 4]
Internet-Draft Group Communication Security for LLN July 2014
solution in this draft. These requirements are same as in
[I-D.keoh-dice-multicast-security] with the additional requirement on
source authentication within the group.
The security requirements which are out-of-scope of this draft and
assumed to be already fulfilled:
a. Establishment of a 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 LLN, or a remote server outside the LLN
could play the role of the group controller. However, GSA
establishment is outside the scope of this draft, and it is
anticipated that an activity in IETF dedicated to the design of a
generic key management scheme for the LLN will include this
feature preferably based on [RFC3740], [RFC4046] and [RFC4535].
b. 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.
c. 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.
d. 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 confidentiality.
The security requirements which need to be fulfilled by the solution
described in this draft:
a. 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.
b. Multicast group size: The security solutions should support the
typical group sizes that "Group Communication for CoAP" draft
Kumar Expires January 3, 2015 [Page 5]
Internet-Draft Group Communication Security for LLN July 2014
[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 LLNs, the number of Senders is much smaller
than the number of Listeners.
c. Multicast data confidentiality: Multicast message should be
encrypted within the group, as some group messages when sent in
the clear could pose unforeseen privacy risks to the users of the
system.
d. Multicast data replay protection: It should not be possible to
replay CoAP group messages out-of-order.
e. Multicast data group level authentication and integrity: It
should be possible to verify if the multicast message originated
within the group and that messages have not been tampered by non-
group members.
f. Multicast data source authentication: Source authenticity is
required if the group members are assumed to be untrusted and can
tamper with the multicast messages. This can happen if nodes of
the group can be easily compromised. Source authenticity helps
to minimize the risk of any node compromise leading to the
compromise of the whole multicast group. Source authenticity can
be typically provided using public-key cryptography in which
every multicast message is signed by the sender.
3. Overview for Secure Group Communication
This section first describes how group communication based on the
underlying IP multicast works and then describe the security solution
at an abstract level.
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 or Listener does not require any prior access
procedures or authentication to send or listen to a multicast message
[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,
Kumar Expires January 3, 2015 [Page 6]
Internet-Draft Group Communication Security for LLN July 2014
signaling its intent to receive packets sent to that particular IPv6
multicast group. Figure 1 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 [I-D.ietf-core-groupcomm]. This
draft does not intend to modify any of the underlying group
communication or multicast routing protocols.
++++
|. |
--| ++++
++++ / ++|. |
|A |---------| ++++
| | \ ++|B |
++++ \-----| |
Sender ++++
Listeners
Figure 1: The roles of nodes in a 1-to-N multicast communication
topology
3.2. Abstract model for securing group communication
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 [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and
Resource Directory [I-D.ietf-core-resource-directory]. The group
controller communicates with individual device to add them to the new
group. Additionally it distributes the GSA consisting of keying
material, security policies, security parameters and ciphersuites
using a standardized key management for LLN which is outside the
scope of this draft.
For the solution defined in this draft, the GSA should at least
contain the following parameters:
o Selectors:
Kumar Expires January 3, 2015 [Page 7]
Internet-Draft Group Communication Security for LLN July 2014
* A "GSA context" identifier to allow Listeners to identify the
GSA parameters being used by the Senders.
* A unique "Sender ID" for each Sender.
o Cryptographic ciphersuites:
* PKC signature algorithm and its public parameters.
* Symmetric-key encryption algorithm and mode of operation.
* Symmetric-key Message Authentication Code (MAC) algorithm (can
be combined with AEAD mode for encryption)
o Cryptographic keys:
* The individual PKC private-key at the Senders and all (PKC
public-key, Sender ID) pairs at Listeners
* Symmetric-key Encryption algorithm group key
* Symmetric-key MAC algorithm group key (not needed if AEAD mode
used for encryption)
Additionally Senders and Listeners need to store additional "Security
Parameters" that are updated when sending or receiving messages:
o Senders:
* Last used sequence number (initially set to zero).
o Listeners:
* For each Sender, the sequence number of the last received
packet that passed authentication.
3.2.1. Sending Secure Multicast Messages
Senders in the group secure a group communication message consisting
of a payload header (e.g. CoAP header) and the payload, as per the
following abstract rules to create the structure as shown Figure 2 :
a. Attach Protocol ID: Identifies to Listener that group
communication security is enabled and the version being used.
b. Attach current GSA context: Identifies to Listener which
cryptographic suites and keys are being used for securing the
message.
Kumar Expires January 3, 2015 [Page 8]
Internet-Draft Group Communication Security for LLN July 2014
c. Attach Sender ID: Identifies the Sender within the group which is
needed for verifying the source of the message.
d. Attach Sequence Number: Indicates the order of messages sent to
prevent replay attacks. The Sender increments the Sequence
Number stored in its "Security Parameters" and attaches it here.
The "GSA context", "Sender ID" and "Sequence Number" together can
be used to construct the nonce or IV if needed for the
cryptographic mode of operation. The exact details on the
construction can be defined during GSA establishment within the
cryptographic suite.
e. SIG: PKC signature for source authentication using the Sender's
private key. The fields "Protocol ID", "GSA context", "Sender
ID", "Sequence Number", "Payload header" and "Payload" are
signed.
f. Based on the GSA context (i.e. symmetric-key encryption algorithm
is not NULL), then "Payload" and "SIG" are encrypted
g. MAC: All fields are authenticated using the MAC algorithm.
A MAC is performed in addition to the SIG to provide a basic Denial-
of-Service protection from devices performing the more
computationally intensive PKC verification operations on bogus
messages from outside the group. If the MAC key is compromised, then
a device observes that MAC verification succeeds while the SIG
verification fails. It can then raise an alarm with its controller
so that it can revoke and create a new MAC key for the whole group.
+--------+---------+--------+----------+---------+---------+-----+-----+
|Protocol| GSA | Sender | Sequence | Payload | Payload | SIG | MAC |
| ID | context | ID | Number | Header | | | |
+--------+---------+--------+----------+---------+---------+-----+-----+
<---------------Private-key Signed fields----------------------->
<--Encrypted-->
fields
<------------------Symmetric-key MACed fields-------------------------->
Figure 2: Abstract model for protection of group messages
3.2.2. Receiving Secure Multicast Messages
When a Listener receives a protected group communication message, it
verifies the message as per the following abstract rules:
Kumar Expires January 3, 2015 [Page 9]
Internet-Draft Group Communication Security for LLN July 2014
a. Read Protocol ID: Identifies that group communication security is
enabled and the version being used.
b. Read GSA context: If the GSA context is known to the Listener,
the rest of the message is verified and decrypted using the GSA
cryptographic suites and keys. If the GSA context is not known
to the Listener, the message is silently dropped.
c. Read Sender ID: Identifies the Sender within the group based on
which the Listener can lookup the appropriate PKC public-key and
stored "Sequence Number" to be used for further processing.
d. Read Sequence Number: Listener checks if the received "Sequence
Number" is greater (or within a sliding window) of the stored
last seen "Sequence Number" for this Sender. If not the packer
is dropped.
e. Verify MAC: Verify MAC based on the group key. If failure, then
drop packet.
f. Based on the GSA context (i.e. symmetric-key encryption algorithm
is not NULL), decrypt the Payload and SIG fields.
g. Verify SIG: Verify PKC signature for source authentication using
the public-key for the Sender ID.
* If success, the stored "Sequence Number" for the Sender is
updated in the "Security Parameters". Furthermore the payload
header and payload is sent to the application to be further
processed.
* If failure, drop the packet and inform controller about an
inconsistency between a MAC verification success and SIG
verification failure. This could indicate the compromise of
the group key.
4. Specific solutions for Group Communication Security
This section describes two specific alternative solutions to
[I-D.keoh-dice-multicast-security] based on the abstract reference
solution described in the previous section. The first alternative
implements the solution directly into the CoAP message while the
second solution is defined as a shim layer between the CoAP and UDP
layer. The second solution can also be adapted to DTLS record layer
if needed.
Kumar Expires January 3, 2015 [Page 10]
Internet-Draft Group Communication Security for LLN July 2014
4.1. CoAP based solution
In this solution, the security of group messages are diretly included
inside the CoAP group message as shown in Figure 3.
+--------+----------------------------------------------+
| | +--------+---------------------------------+ |
| | | | +-------+-----------+---------+ | |
| IP | | UDP | | CoAP | CoAP | CoAP | | |
| header | | header | | Header| Options | Payload | | |
| | | | | |[Security] | [SIG] | | |
| | | | | |[ Header ] | [MAC] | | |
| | | | +-------+-----------+---------+ | |
| | +--------+---------------------------------+ |
+--------+----------------------------------------------+
Figure 3: Group communication security within CoAP
The "Protocol ID", "GSA context", "Sender ID" and "Sequence Number"
are carried as additional options in Type-Length-Value (TLV) format
within the CoAP Options field indicated as "Security Header" in
Figure 3. (More details on the options, like class etc., needs to be
further expanded in a newer version of the draft.) The PKC signature
SIG is generated over the combined CoAP Header, CoAP Options and the
original CoAP payload. This SIG is concatenated to the original CoAP
payload, and these together can be further encrypted based on the
ciphersuite defined in the GSA. Finally the MAC is computed over the
CoAP Header, CoAP options and the new (encrypted) CoAP Payload and
concatenated into the CoAP payload field.
The creation of the secure group message by the Sender and
verification by the Listener are same as described in the abstract
model, except that the corresponding values need to be read from the
correct locations within the CoAP Options and CoAP Payload.
4.2. Shim layer solution
In this solution, the security of group messages closely matches the
abstract model shown in Figure 2. The payload header are the
original CoAP header and CoAP options field. The payload is the CoAP
payload. The shim layer carries the rest of the headers; "Protocol
ID", "GSA context", "Sender ID" and "Sequence Number" (indicated as
"Security Header") as well as the SIG and MAC fields. The solution
is as shown in Figure 4.
Kumar Expires January 3, 2015 [Page 11]
Internet-Draft Group Communication Security for LLN July 2014
+------+---------------------------------------------------------------+
| | +------+----------------------------------------------------+ |
| | | | +----------+---------Shim Layer------+-----+-----+ | |
| | | | | +-------+--------+--------+ | | | |
| IP | | UDP | |[Security]| CoAP | CoAP | CoAP | | | | |
|header| |header| |[ Header ]| Header| Options| Payload| SIG | MAC | | |
| | | | | +-------+--------+--------+ | | | |
| | | | +----------+-------------------------+-----+-----+ | |
| | +------+----------------------------------------------------+ |
+------+---------------------------------------------------------------+
Figure 4: Group communication security with Shim Layer
The creation of the secure group message by the Sender and
verification by the receiver are same as described in the abstract
model except for the different positioning of the fields.
4.3. Comparison between the solutions
This is a first comparison between the solutions and needs to be
further refined.
The solutions described in this draft use more computationally
intensive operations based on PKC for each and every individual
message. This can be quite demanding on many cheap IoT devices which
have strong memory and power constraints. Also compared to the
solution in [I-D.keoh-dice-multicast-security], the current solutions
require new code for securing group communication and cannot reuse
parts of the existing code used to protect unicast communication.
Furthermore the CoAP based solution requires changes in the CoAP
layer and requires different handling for group messages compared to
unicast communication.
The Shim layer solution is transparent for the CoAP layer and can
also be reused for other multicast protocols over UDP. The Shim
layer solution, if needed, can also be adapted to DTLS record layer
with some additional changes to the DTLS record format.
5. IANA Considerations
This memo includes no request to IANA.
Kumar Expires January 3, 2015 [Page 12]
Internet-Draft Group Communication Security for LLN July 2014
6. Security Considerations
Some of the security issues that should be taken into consideration
are discussed below.
6.1. Group level confidentiality
This proposal uses a single group key to provide confidentiality of
the communication within the group. This is a weak form of
confidentiality and for most IoT scenarios where group commuication
is used to send commands, this suffices.
6.2. Late joiners
Listeners who are late joiners to a multicast group, do not know the
current GSA context and Sequence Number being used by different
Senders. When they receive a packet from a Sender with a random
Sequence 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 as a
additional Listener role in the multicast group can maintain the list
of last seen Sequence Number of each sender. When late joiners sends
a request to the group controller to join the multicast group, the
group controller can send this list as part of the GSA.
6.3. Uniqueness of Sender IDs
It is important that Sender IDs are unique to maintain the security
properties. Since the group controller assigns the Sender IDs, it
should ensure the uniqueness within the group.
6.4. Sequence number space
The "Sequence Number" space should be defined large enough to avoid
changing the GSA context often due to wrap over. The controller can
create a new GSA context when Sequence Number approaches exhaustion.
This should be done as part of the key management mechanism which is
out-of-scope of this draft.
7. Acknowledgements
The authors greatly acknowledge discussion, comments and feedback
from Dee Denteneer, Peter van der Stok, Zach Shelby and Michael
StJohns. Also thank Tanja Lange and Daniel J. Bernstein for the
useful discussion and comments.
Kumar Expires January 3, 2015 [Page 13]
Internet-Draft Group Communication Security for LLN July 2014
8. References
8.1. Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-19 (work in progress), June
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012.
8.2. Informative References
[FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[FIPS.197.2001]
National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001,
<http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>.
Kumar Expires January 3, 2015 [Page 14]
Internet-Draft Group Communication Security for LLN July 2014
[I-D.dijk-core-groupcomm-misc]
Dijk, E. and A. Rahman, "Miscellaneous CoAP Group
Communication Topics", draft-dijk-core-groupcomm-misc-06
(work in progress), June 2014.
[I-D.ietf-core-resource-directory]
Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", draft-ietf-core-resource-directory-01 (work in
progress), December 2013.
[I-D.keoh-dice-multicast-security]
Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Rahman, "DTLS-based Multicast Security in Constrained
Environments", draft-keoh-dice-multicast-security-07 (work
in progress), May 2014.
[I-D.mcgrew-aero]
McGrew, D. and J. Foley, "Authenticated Encryption with
Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in
progress), February 2014.
[I-D.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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
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.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
Kumar Expires January 3, 2015 [Page 15]
Internet-Draft Group Communication Security for LLN July 2014
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[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.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
Author's Address
Sandeep S. Kumar
Philips Research
High Tech Campus 34
Eindhoven 5656 AE
NL
Email: sandeep.kumar@philips.com
Kumar Expires January 3, 2015 [Page 16]
